Wanted - "Modules" for Spring

[Bosmon]

I'm looking for a project that builds some kind of explicit superstructure on Spring contexts, managing the process of creating context assemblies with respect to parent->child relationships, and/or overriding relationships.

To be a bit more concrete, a system that will accept "modules" in the form of JARs together with embedded Spring context definition files (XML), as well as possibly some form of external "meta-context" definition file that declares the desired mutual dependence relations between the contexts. A more cool idea would be if the contexts only internally declared "relative" dependencies, and the "modules" system determined the correct context wiring order in much the same way Spring contexts determine correct wiring order of their component beans.

Anyone know of or is working on such a system? I guess another way of looking at this might be something like the HiveMind module descriptor system. Only, as befits the Spring model, something a bit more conceptually slimline :P

Cheers,
Antranig.

I was hoping that "Spring Modules" might turn out to be a system like this, but was a little disappointed to find out it was just a set of modules for Spring, rather than a system for making modules for Spring :P

[devijvers]

Just use this location string to load you Spring XML files:

classpath*:/META-INF/MyContextFile.xml

You can now add one of these files to every jar. All files will be loaded in one ApplicationContext and you can add more locations.

[Bosmon]

That's exactly what I am trying to avoid.

The point is that the artefacts should be autonomous, and not incur costs in web.xml proportional to the number of modules being used. The problem is now that with increasing numbers of modules in my framework, the burden is on clients to i) list all these classpath context files, and ii) get them in the right order! in the case where the contexts are meant to form an overriding set. This is a fragile process, annoying and prone to error.

Actually I'm surprised at the lack of this, since it implies that noone at the moment is doing component-based development in Spring, which is odd since it's so marvellously suited to it. Does this mean then that the vast majority of developers are using single (or a small number of) "app-wide" monolithic containers, and not using a model where the context is built up modularly, possibly with code from many sources?

[devijvers]

I've actually used this approach to build a component based architecture for Grails. JARs can be added to the classpath that include a /META-INF/GrailsPlugins.xml file and the components are automatically loaded.

However, we soon realized we also needed a way to disable components on request. For example, if you want to replace a functionality in Grails with your own custom functionality you have to be able to disable the original component and replace it with yours.

The trick is to keep things simple. One ApplicationContext is sufficient for this. We've added a voter mechanism where any component can choose to disable other ones. The level of granuality is decided per component so they can choose to be disabled as a whole or offer options to be disabled.

And all this works with the regular Spring ApplicationContext and just one line for configContextLocation:

classpath*:META-INF/GrailsPlugins.xml

[Bosmon]

Well, this sounds very cool, although IMO it would be "cleaner" to stay with the IoC idiom amongst component files as well as within them. My current concept is simply to assign a "dependence order" amongst contexts, probably based on some kind of explicit declaration (although it might be possible, though dangerous, to "infer" this through spotting potential overriding/replacement/usage patterns in the files). Within RSF I also use a single ApplicationContext, but component replacement is performed through simple overriding.

The "multiple classpath" syntax theoretically would solve this, but the problem as I mentioned is ordering - since "replacement by overriding" requires precise control over the order component files are loaded. This problem in your case you solve by the "component voting scheme". I would also like to give users the option to use parent/child contexts rather than overriding ones.

I'm still amazed that there is nothing "off the shelf" or part of Spring that is aimed at this issue. As soon as I saw parent and child Spring contexts, I immediately thought "now, there must surely be some kind of 'meta-context' file that you declare these relationships in, otherwise how would they get assembled?" - but it does appear that in the 'real world' (at least the open source real world) people really are just assembling their Spring contexts by hand in code. Not very Spring if you ask me :P

Is the code for your components loader a fairly hack-offable lump of source? Or could you throw me an SVN link to it since it doesn't immediately jump out while browsing your FishEye :P

Cheers