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

[Estes, J. D - S. L. M. <jam...@us...>]

I've been thinking about this quite a bit lately.  My first instinct
when using Spring was that I should be able to do this...but as I
learned more about Spring and dependency injection, I felt it was not
appropriate to be able to do includes in a bean file.  What it amounts
to is a dependency that you are allowing the bean file itself to seek
out and resolve...instead of allowing the caller/container/environment
do this for you by loading all the appropriate configs together (or
through a parent hierarchy).

Example: =20
You have an Application Context XML file that contains your DAO beans,
but you want your JUnit tests to run with a different dataSource (dbcp)
than your actual web application (jndi).  So you have 3 xml files:  the
main dao xml, a dbcp dataSource xml file, and a jndi dataSource xml
file. =20
With the include approach, my dao file would directly point to the
implementation I want, and I would have to change it (or use ant to do
it for me) when I switch between the 2 environments. =20
If I use the injection approach, my JUnit would setup a hierarchy with
the dao xml and the dbcp dataSource xml by directly creating an instance
of the ClassPathXmlApplicationContext with the 2 files as the
configLocations.  The Web Application would load the dao xml and the
jndi dataSource xml via the configLocation (using classpath: pathname
for the dao and normal file path for the jndi xml file).  No complex
changes are required for it to work in both instances.  The dependencies
are resolved appropriately by the application in use.

It would be nice (for clarity/documentation purposes) to be able to
define abstract beans in the file.  Essentially a placeholder saying "I
know this bean is not in this file, but it is assumed that it will be
provided by another xml file in the same or parent container".  And then
possibly have a validation error when a container (once composed) does
not have an 'implementation' for the bean.  This essentially already
happens by just referencing the bean, but again, the abstract bean would
just be for clarity.

I can, however see the need for more easily composing and packaging a
set of bean files.  If my dao project internally used several xml config
files, I would not want to force the main project to know that much
about the internals of the dao project (e.g. "To use this dao, pull the
jar in and then create your spring application context with the
following xml files present:  classpath:com/foo/dao/DaoCore-context.xml,
classpath:com/foo/dao/DaoFinance-context.xml,
classpath:com/foo/dao/DaoUsers-context.xml,
Classpath:com/foo/dao/DaoHibernate-context.xml). =20

For this kind of purpose, I think the include would be nice, but I would
want to keep includes out of my actual bean files and have a special
kind of composite bean file that has includes in it (or I would just
keep them separate myself in practice, but I think it keeps things more
clean this way).  It would also be possible to have a springindex: type
of path that would point to a special kind of bean file (on the
classpath or in the file system) with a list/include of the bean config
files that should be loaded from the classpath.=20
So for my example above, the dao would be in a jar along with a
dao-index.xml file that pointed to each of the needed files.  And I
could include them all in my web application context with a config
location of springindex:com/foo/dao/dao-index.xml.  OR if Spring does
allow include directives, I would (again keeping the include or
composition file separate) have a config location of
classpath:com/foo/dao/dao-index.xml.


Just my thoughts.

James