Spring DM and regular spring!

[cutout33]

Hello,

I am making a research for using spring DM, now if I want to use Hibernate controlled by spring do I need a new implementation or my old one (hibernate+spring) will work just fine? also this for any other spring impl. (i.e. RMI, AOP, PropertyPlaceholderConfigurer...etc.).

Thanks in advance

[schaeferc]

From my experience so far with Spring DM, I have found Spring DM is really just a set of extra bundles that makes the running of a spring container more or less transparent and allows spring beans to be used between springified OSGi bundles.

That said I have found that Spring DM 1.1.2 for instance is only validated against Spring standard release 2.5.5. It is also only validated against specific versions of each main OSGi container . So there are some usage constraints.

The challenging part was not really Spring DM, as after sorting out all the versioning issues it runs transparently. The challenge is actually how to divide up an existing application into OSGi bundles and decide which bundles will offer which Spring beans as OSGi services. If your current application code is not packaged in an OSGi friendly way then refactoring is necessary. But that is not really a Spring DM issue

[cutout33]

OK, thanks my project is to be developed yet so I have to to care of the design from the beginning, but this leads me to another question, Now if after developing my application I wanted to move from Equinox to Felix or Knopflerfish. what are the steps is there anything to be changed in my application?

Thanks again

[schaeferc]

In theory moving between OSGi containers should be fully transparent and there is nothing to be done to the bundle design of the application.

In practice this is almost true. As we are all users of Spring DM for our springified bundles you are constrained to specific versions of each OSGi container that the Spring DM version you are using is tested against. That is why is is really important to read the supported versions in the documentation of each Spring DM release as I linked-in above.

For instance I started using the latest version of felix but the Spring DM would not load correctly. After using the correct version of felix everything was ok and I am currently moving between knopler, equinox and felix as I develop. For eclipse based development I use equinox as it works and I see no need to therefore load in knopler or felix into eclipse. I am actually using equinox 3.4.2, which is technically not integrated against Spring DM but it works so far. Otherwise I have found knoplerfish to be more user friendly and a little more robust than felix when using stand-alone OSGi containers. The Knoplerfish GUI is certainly a great tool for administering bundles and visualising dependencies.

[cutout33]

Hi,

This is was really helpful, am considering knopflerfish for production and equinox for development, but I had to ask this before starting.

Am going to get busy

Thanks

[Costin Leau]

Regarding the Hibernate application - using Hibernate on raw OSGi requires some tweaks due to the weaving and class loading done by the library with respect to your domain model. There are several blogs on why is that including an entry by Peter Kriens.
For such applications and requirements, dm Server is a much better candidate then Spring DM as it provides an OSGi aware runtime environment.
Back to Spring DM and its requirements - we do our best to try the library on as many versions of Equinox/Knopflerfish/Felix. Based on our experience, upgrading to newer versions should not cause problems however you should run some tests to be on the safe side.
Spring DM is based only on the OSGi API so as long as the new versions do not break the OSGi semantics, things should be in order. The only part where the 'custom' APIs are used is the testing framework (for bootstrapping) but so far we had only one problem with upgrading to Felix 1.4.1 which was backwards incompatible but this was fixed in a matter of days.

These being said, if you have any issues with newer versions of the libraries, let us know and we'll do our best to fix these.

[cutout33]

Thanks for the hint about hibernate I'll be doing a research before I start.

[cutout33]

Regarding the Hibernate application - using Hibernate on raw OSGi requires some tweaks due to the weaving and class loading done by the library with respect to your domain model. There are several blogs on why is that including an entry by Peter Kriens.
For such applications and requirements, dm Server is a much better candidate then Spring DM as it provides an OSGi aware runtime environment.
Back to Spring DM and its requirements - we do our best to try the library on as many versions of Equinox/Knopflerfish/Felix. Based on our experience, upgrading to newer versions should not cause problems however you should run some tests to be on the safe side.
Spring DM is based only on the OSGi API so as long as the new versions do not break the OSGi semantics, things should be in order. The only part where the 'custom' APIs are used is the testing framework (for bootstrapping) but so far we had only one problem with upgrading to Felix 1.4.1 which was backwards incompatible but this was fixed in a matter of days.

These being said, if you have any issues with newer versions of the libraries, let us know and we'll do our best to fix these.

Does the tweaks for hibernate apply to Toplink too?

[Costin Leau]

From a generic point of view, they might however Toplink (or nowadays EclipseLink) is more aware of OSGi so it might work out of the box. I haven't used it myself but see this blog entry for more information: http://blog.springsource.com/2008/07...tion-platform/

[cutout33]

Thanks for the link and the quick replay!