Re: [Springframework-developer] Import tag for XML bean definitions

[Tom T. <tom...@pr...>]

This would be useful for "composed bean definition files" packaged in an
api jar file. We usually split up larger bean definition files by
functional domain, but this separation does not always make sense for the
application that uses the jar file.

It would be nice if the application using the jar file could just specify
a single contextConfigLocation, without knowing whether this file is
actually "composed" or not. In the "composed" case, the actual file would
probably consist of only import tags.

Maybe an <import resource=3D"classpath:/mypackage/imported.xml"/> syntax
would be more obvious? Or maybe "file" is always relative against the
current location?

Kind regards,
Tom.

On Fri, 4 Jun 2004 10:29:38 +0200, "j=FCrgen h=F6ller [werk3AT]"
<jue...@we...> said:
> We've got an enhancements request in JIRA, currently for the 1.0.3
> timeframe:
>=20=20
> http://opensource.atlassian.com/projects/spring/browse/SPR-137
>=20=20
> Essentially, it's about an <import> tag that allows to specify imports
> within an application context XML file rather than in an external
> "contextConfigLocation" setting - imports driven by the XML file itself
> rather than from the outside.
>=20=20
> <import file=3D'imported.xml'/>
>=20=20
> <beans>
>=20=20
>   ...
>=20=20
> </beans>
>=20
> Something similar can already be achieved with XML entity includes, but
> those are arguably not very convenient to use. XWork has such an <import>
> tag, BTW; Mike Cannon-Brookes has already suggested this for Spring a
> couple of months ago too.
>=20=20
> I wouldn't mind adding such an option, although I still prefer external
> contextConfigLocations. It does have some effects on our
> XmlBeanDefinitionReader/Parser signatures, though, as a ResourceLoader is
> needed by the parser now for resolving those import locations. This
> indicates that it might be better to introduce this for 1.1 rather than
> for 1.0.3, I guess.=20
>=20=20
> Thoughts?
>=20=20
> Juergen
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer