Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-06-25 17:06:11
|
Any thoughts on include/import directives in XML bean definition files? http://opensource.atlassian.com/projects/spring/browse/SPR-137 This is about elements in XML bean definitions that allow to include = other XML bean definition files, with paths that are interpreted as = relative to the current file. Basically, this is an alternative to = combining multiple XML bean definition files via "contextConfigLocation" = parameters. =20 Remaining questions are mostly about syntax. One possibility would be = like as follows: =20 <beans> =20 <include resource=3D"includeBeans.xml"/> =20 <bean.../> =20 </beans> =20 Should the tag be called "include" or "import"? Any suggestions or = objections regarding such functionality in general? I'm personally still = a fan of "contextConfigLocation", but I guess there are valid use cases = for keeping includes directly in bean definition files. =20 As a side note, one can already use standard XML entity includes to = achieve something similar. However, such include files are not full = DTD-compliant XML files themselves, and the XML include syntax is rather = awkward. =20 <?xml version=3D"1.0" encoding=3D"UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" = "http://www.springframework.org/dtd/spring-beans.dtd = <http://www.springframework.org/dtd/spring-beans.dtd> " [ <!ENTITY contextInclude SYSTEM = "org/springframework/web/context/WEB-INF/contextInclude.xml"> ]> <beans> =20 &contextInclude; =20 <bean.../> =20 </beans> =20 I'd like to clarify our way to proceed with this ASAP, to get it into = 1.1 RC1 if we decide to adopt it. =20 Juergen |
|
From: Timo V. <sic...@gm...> - 2004-06-25 17:33:52
|
Hi! Why not use standardized XInclude syntax? It would look like this: <beans xnlns:xi=3D"http://www.w3.org/2001/XInclude"> ... <xi:include href=3D"anyURL"/> ... </beans> XInclude supports inclusion of xml and text data; thus it could replace=20 annoying CDATA sections. Regards, Timo Am Freitag, 25. Juni 2004 19:06 schrieb j=FCrgen h=F6ller [werk3AT]: > Any thoughts on include/import directives in XML bean definition > files? > > http://opensource.atlassian.com/projects/spring/browse/SPR-137 > > This is about elements in XML bean definitions that allow to include > other XML bean definition files, with paths that are interpreted as > relative to the current file. Basically, this is an alternative to > combining multiple XML bean definition files via > "contextConfigLocation" parameters. > > Remaining questions are mostly about syntax. One possibility would be > like as follows: > > <beans> > > <include resource=3D"includeBeans.xml"/> > > <bean.../> > > </beans> > > Should the tag be called "include" or "import"? Any suggestions or > objections regarding such functionality in general? I'm personally > still a fan of "contextConfigLocation", but I guess there are valid > use cases for keeping includes directly in bean definition files. > > As a side note, one can already use standard XML entity includes to > achieve something similar. However, such include files are not full > DTD-compliant XML files themselves, and the XML include syntax is > rather awkward. > > <?xml version=3D"1.0" encoding=3D"UTF-8"?> > <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" > "http://www.springframework.org/dtd/spring-beans.dtd > <http://www.springframework.org/dtd/spring-beans.dtd> " [ <!ENTITY > contextInclude SYSTEM > "org/springframework/web/context/WEB-INF/contextInclude.xml"> ]> > > <beans> > > &contextInclude; > > > <bean.../> > > </beans> > > I'd like to clarify our way to proceed with this ASAP, to get it into > 1.1 RC1 if we decide to adopt it. > > Juergen > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-develope >r |
|
From: Colin S. <col...@ex...> - 2004-06-25 18:01:22
|
I don't have anything against this really, but on the other hand I think people would almost always be better of specifying the files to be combined from the external creator of the BeanFactory or ApplicationContext, which Spring allows you to do pretty easilly everywhere, in that almost everywhere you can specify one file, you can specify multiple files. My feeling (although I haven't verified it) is that the relative import is probably going to fail in a classpath resource situation anywehre where the file is not actually on the filesystem. For example, in WebLogic, jar files with classes are usually not actually expanded out to the filesystem. So if you get the URL for one of these resources, you'll get zip:path/to/jar/file/jarfile.jar#real/path/to/resource now I think the code in the patch would fail when it tries to build a relative URL for the imported relative fragment, where it calls new URL(this.url, relativePath) Of course this will work in many situations, but people are probably better off doing something portable. So if we add it, we should probably strongly suggest that people try to avoid using the import and specify the files externally. Colin jürgen höller [werk3AT] wrote: >Any thoughts on include/import directives in XML bean definition files? > >http://opensource.atlassian.com/projects/spring/browse/SPR-137 > >This is about elements in XML bean definitions that allow to include other XML bean definition files, with paths that are interpreted as relative to the current file. Basically, this is an alternative to combining multiple XML bean definition files via "contextConfigLocation" parameters. > >Remaining questions are mostly about syntax. One possibility would be like as follows: > > <beans> > > <include resource="includeBeans.xml"/> > > <bean.../> > > </beans> > >Should the tag be called "include" or "import"? Any suggestions or objections regarding such functionality in general? I'm personally still a fan of "contextConfigLocation", but I guess there are valid use cases for keeping includes directly in bean definition files. > >As a side note, one can already use standard XML entity includes to achieve something similar. However, such include files are not full DTD-compliant XML files themselves, and the XML include syntax is rather awkward. > > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd <http://www.springframework.org/dtd/spring-beans.dtd> " [ > <!ENTITY contextInclude SYSTEM "org/springframework/web/context/WEB-INF/contextInclude.xml"> > ]> > > <beans> > > &contextInclude; > > > <bean.../> > > </beans> > >I'd like to clarify our way to proceed with this ASAP, to get it into 1.1 RC1 if we decide to adopt it. > >Juergen > > |
