why is context hierarchy a tree and not a graph?

[sam26]

I was thinking more about this last night on the ride home and thought it would be silly to use namespaces within classes when requesting beans... What's IoC for if not to avoid tying you to things like that.

Rod mentioned in his post and in his book, "J2EE Development without EJB" on page 177 that:

You can also specify multiple file locations to be merged into a single application context instance. Each file must conform to the DTD; they can refer to each other's beans with normal bean references. This is useful for splitting up large middle tier application contexts, for example by module or into business context and a data access context.

While there is an example given of a context instance being loaded from a single xml file, I would have loved to have seen an example of more than one file being used to load a context.

ClassPathXmlApplicationContext's constructor with a single String was used. However, there are several constructors, and some allow you to supply a String[] of resource xmls.
:arrow: ClassPathXmlApplicationContext

[Colin Sampaleanu]

While there is an example given of a context instance being loaded from a single xml file, I would have loved to have seen an example of more than one file being used to load a context.

Just take a look at the jpetstore sample, it builds a context from two xml fragments, specified in the web.xml file.

One related note, you can very nicely use aliases (having both an id as well as one or more extra names) on beans, to tie together components, yet keep them unaware of each other.

Colin

[memelet]

I've been on holiday, so I've missed this very important topic. I too am srpingizing a system that uses a plugin module similar to eclipse (except we define extension points and extensions directly in the spring config files!). However, the limitation of a tree for context is a dead-end.

Heres what I'm doing to get around the tree limitation:

- All beans have a unique prefix (equivilent to the eclipse plugin-id)
- A bootstrap layer determines the full set of plugins installed for the app, and loads all plugin context files into a single appContext.
- There is no support limiting visibility between plugins. That is, a plugin does not have speciify which other plugins it depends on. (I don't like this, but its the only I way I can make this work. In practice, however, I can live with it).

Of course, I would much rather have some explicit support for a plugin framework within spring.

[stepper]

memelet,

in fact what you are doing sounds very similar to my solution to the plugin challenge. as the unique prefix you mention i use the path down in the (named) context hierarchy. this way i get a "full qualified" bean name which is also used as the logging category and the logging hierarchy does not differ from the runtime hierarchy of objects (beans).

if you are interested in my experiences with eclipse as a plugin environment, you could have a look at my Net4j project. it is open source and uses eclipse at client- and server-side to build upon a sophisticated plugin technology. at server-side i use a socalled "headless" eclipse environment (1mb disk space and 1 sec startup time).

the code is full functional and half tested. unfortunately the documentation is already outdated with respect to the chosen environment, because my first try was with merlin/avalon plus eclipse. for other reasons i'm forced to update the docs soon (and submit a first proper release). if you'd like to have a first look, try http://net4j.berlios.de

cheers
/eike