one context for multiple bundles

[SlowStrider]

Is it possible to combine spring xml config files from different bundles into one Spring context? (This is probably against the idea of Spring DM but see my detailed explanation below why I would like to do this.)

I tried this by making an extra bundle "a" with one Spring xml file that uses several lines like

<import resource="context-from-bundle-b.xml" />
<import resource="context-from-bundle-c.xml" />

where the first context file is inside bundle b and the second in bundle c. Unfortunately the Spring extender cannot find xml files from other bundles this way.




------------------------------------------------
Gory details below, skip at own will
------------------------------------------------
We have an Eclipse workspace that contains some plain java projects (buildable by Maven): one core java project and several different java projects that each add an aspect to beans of the core project by having extra spring xml context files. These need to be combined into one Spring context.
Furthermore we depend on classpath scanning to instantiate the necessary beans.

This is no problem at all outside of OSGi: we have one "integration" project that depends on all the java projects so that we can get everything on one classpath. We use this to start up a non-osgi server.

However, we need to use Eclipse RCP for the client which requires our code to be an OSGi Bundle. Again we have no problem at all using the maven bundle plugin to build one bundle from multiple java projects. Having everything in one bundle works fine for us.

However, everytime we change only the tiniest bit in one java file we need to rebuild the entire bundle and put the resulting jar on the target platform. This drains programming efficiency enormously. We would like to be able to use Eclipse's incremental compiler and source code linking.

One possible solution for this is to make all our java projects into OSGi bundles/Eclipse plugins. But when we do this, each project will get it's own Spring context so that classpath scanning and AOP across java projects will not work the same way as before.

One solution which I unfortunately must take if everything else fails is to put all our code into one java project and use a package-per-module structure.

So the other idea I have is by making each project an OSGi bundle that simply exports everything and have our "integration" project be an OSGi bundle that depends on each of them and combines all spring xml configuration into one context.

I know it is possible to do this by placing each spring context file into the "integration" project but then our "unit" tests cannot find their spring context anymore.

Another way for the xml file merging would be to make each project an OSGi fragment on the core project. But a bundle can not use interfaces and classes defined in fragments if they only depend on the fragment host bundle.

[SlowStrider]

Ok, after some thought I can live with having one project for our generic system but it should still be separated from our specific domain model project.

We wish to separate our specific business model entities and DAO's from the generic system (called Olga) that handles persistence, security, change notification, caching, remoting, etc... all setup with Spring xml configuration.

The business model DAO's extend from a generic dao in Olga. Olga can find the DAO's and automatically instantiate them and remotely expose them and add AOP advice.

Just like the idea of an abstract class and a concrete implementation which depends on the abstract class, Olga is a complete abstract system which is made concrete by extending it with a specific domain model.

So from a code perspective Olga is quite intimate with the classes in the model (ideally the same classpath) but it has no compile time knowledge of the particular business implementation.

The model is also quite intimate with Olga because it needs Olga's spring configuration to be able to instantiate DAO's and getting the AOP advice applied. But ideally this should be no concern of the model and should be the concern of Olga.

What works perfectly well for our situation is to combine these two in one Spring-DM bundle so that both share the same classpath and Olga can do it's CP scanning and AOP tricks. But I still need them to be two separate projects in my Eclipse workspace! I have no idea how to build one Eclipse plugin from two projects and have incremental compile work correctly. Or how to build two Eclipse plugins that share the same classpath and Spring contexts.

So I will now have to put them in one plugin with the risk of tangling system concerns with the business model and making it much harder to reuse Olga for other business models.

[SlowStrider]

Well here is my own answer at the moment...

I think for my problem there is no escape from putting the boilerplate code containing "system bundle" (what I called Olga) into one Eclipse project instead of one project per aspect.

Registering domain model entities and instantiating and exposing dao's/services could ultimately done by using an extender pattern of our own or by using equinox extension points but I don't see how this works nice with Spring-DM so I will not start this adventure at the moment and just put our domain model in the same bundle....