Friday, October 15, 2010

Spring Extension Factory now on Github

Two years ago I wrote a tiny little piece of software that lets you combine Spring Dynamic Modules and the Equinox Extension Registry in an easy way. Now I found the time to put this SpringExtensionFactory on Github. So if you ever wanted to use Spring Dynamic Modules to inject dependencies into your RCP view and editors - take a look, its quite simple to use... :-)

5 comments:

Unknown said...

Hi Martin thanks for the very helpful extension. I've been using it for a few weeks and it works great, or it did before I recently learned the tag inside my spring context.xmls. Now everything blows up if I use these. The only workaround I know is to not use these, which means a lot of copied xml between modules where module a uses b uses c uses d etc. Am I missing something in my rcp configuration?

Unknown said...

Looks like the above comment clipped my xml tag which is the nut of my question.

The element that blows up is my context.xml is the import resource element.

Martin Lippert said...

Hi Pete!

Within an OSGi environment working with Spring-DM, you should not use the import tag to access beans that are defined in other bundles. You should take a look at the osgi namespace features to access beans across OSGi bundle boundaries (using OSGi services via Spring-DM etc.), don't use the import tag.

HTH,
Martin

Unknown said...

Looks like I've got more to learn. I learned my current approach in this springsource screencast:

http://www.springsource.com/training/freeonline/osgi

This shows both osgi:service tags and regular bean tags in separate xml files, so you can run your unit tests in development without firing up the container.

Granted, I can and do run my tests within pax-exam and also inside RCP, but would hope this is not how I work during development of a non-visual module.

I'll experiment a bit and see what happens. So far all I am getting is

BeanCreationException: Could not autowire field: yada

Martin Lippert said...

Hi Pete!

I watched the tutorial you mentioned to make sure I don't misunderstand your setting:

In the tutorial Joris talks about multiple XML config files WITHIN one bundle project to separate OSGi-specific configs from general spring configs. So if you put more than one config file into a bundle, those configs are automatically merged into a single app context at runtime by Spring-DM. You don't need to use the import tag here!!!!!

When you would like to use beans from another bundle, you should use the OSGi namespace to export/import beans as/from OSGi services. This is the preferred way to inject beans from other bundles. Again, you should NOT use the import tag here either!!!!!!

With regards to testing: WITHIN a bundle you separate your bean definitions into separate config files to use your normal Spring beans without OSGi. So if you run your tests without OSGi and configure your tests to just use the normal Spring beans config file and thats it.
The only case where this gets complicated is if you would like to inject a bean from another bundle into your bean under test just for the unit test. But this setting sounds a little bit like the unit test you write as actually not a UNIT test but an integration test or something similar. In that case you should consider running the integration tests as plugin junit tests (having a running OSGi runtime) and use the general spring-dm mechanisms.

HTH,
Martin