This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
With OSGi Blueprint, IBM is showing people how to convert Spring based programs to Blueprint apps for the Websphere 7 and 8 in developerworks article (Migrating from the Spring Framework to OSGi
using the WebSphere Application Server V7 Feature Pack for OSGi Applications -- Run Spring applications in an OSGi container then migrate to a standards-based dependency injection container).
Spring DM is now dead as far as Spring is concerned (their blog has discussions on Spring DM in the attic). Apache Aires Blueprint appears to be the winning Blueprint implementation.
No one from Spring is touching the OSGi layer in blogs etc. So my impression is if you want to go OSGi you will leave Spring behind. Probably should stay away from Spring MVC and go more
toward JSF etc if going OSGi route?
OSGi and your choice of web framework are pretty much orthogonal. I also fail to see why the Spring framework would suffer just because SpringSource decided that Spring DM wasn't the best approach to bringing OSGi into the Spring world.
Joined: Mar 20, 2002
Thank you for your reply. I may be operating on some false assumptions. Is there any XML that is not supported by blueprint, such as Spring AOP xml? refer to "http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14469088" last entry.
Joined: Mar 20, 2002
I agree with your post. I guess I am just trying to sort things out. It appears that it is proper to leave Spring behind and just use the IOC from the OSGi Blueprint spec without the need for introducing any Spring. But if we need to use any of the Spring API we can introduce it as needed and in most cases there will not be any incompatibilities. It does appear that Spring AOP has issues from posts that I have read, but they may be resolved already.
Joined: Sep 21, 2011
Well, ... if IOC is all you need then OSGi is probably overkill, and Spring is a better choice. OSGi *is* a big gun to be used appropriately. But it does solve a whole lot of problems if you're prepared for its learning curve.
I think Spring is far from dead since OSGI in and of itself has seen trouble getting enterpise adoption which is the reason Springsource cited when it discontinued the Spring DM project. That said there is more than IBM when in comes to OSGI. For those who started with Spring DM many may prefer Eclipse Virgo, here is an interesting read:
It will be interesting to see where all of this ends up in a few years, but you can be sure Spring will adapt and find its place it always does.
I would say that if we are just talking about IoC and dependency injection, then OSGi will not replace spring.
This is because OSGi and Spring offer two different things. OSGi is a specification for defining how modules interact. Spring IoC is more generic, it can be applied at any level. Spring DM, AFAIK, was an attempt to define a module specific version of the IoC that adhered to the OSGi standard and yet was a simple extension of the core spring IoC.
I would think that Spring IoC should be used to develop modules, which would be deployed in an OSGi container. Whether Spring or Blueprint is then used to define OSGi services and clients, i.e. how the modules interact, is another matter.
This is of course assuming that the definition of a module will not narrow to any size component of code. In this case, as stated earlier, by using OSGi we would be using a heavyweight tool where a lightweight one would be sufficient.
What happened with Spring-DM is the OSGi folks liked it so much they have incorporated it into the 4.2 specification.
Main change is the element <beans> becomes <blueprint> (and associated xsd references), and META-INF/spring location becomes OSGI-INF/blueprint for the context files.
Otherwise, Spring integrates as before with OSGi, and a sweeter combination for building enterprise java systems I haven't experienced...