Richard, If you're merely wanting to use Karaf as a container to run an application without really being "container aware" than Spring DM is a viable choice due to its familiarity for most developers. I've seen this used successfully for many Camel based applications that didn't explicitly use any container-provided services but merely needed basic life-cycle management. That being said, if you want to leverage services or interact with the underlying container than I strongly recommend sticking with Blueprint. It does a nice job of hiding the dynamism of container-provided services (via proxies) and allows one to wire them using dependency injection. It is this "softening" of the underlying service dynamism that makes Blueprint a great asset, especially for new developers.
Additionally, it's worth noting that Blueprint is comparable to Spring's dependency injection, not the entire Spring ecosystem which encompasses far more than DI. This may seem like a silly point to make, but I have known people to get confused. Best Regards, Steve On Thu, Sep 18, 2014 at 5:04 PM, <[email protected]> wrote: > I have used JPA with DS. It was OK so long as you didn't try to do > anything too fancy - in my case it went adrift when I tried to embed an > enum which was declared in another bundle, spent some time trying to debug > this one but ran into a morass of proxy class loaders holding references > to lists of BundleClassLoaders. To preserve my sanity, I changed my > design. > > Good luck, Chris > >> Richard, these links don't explain the differences between Spring DM and >> Blueprint but may help make up your mind, although note that since some of >> the statements were made things may have changed. In summary it doesn't >> appear clear (to me at least) where Spring-OSGI is heading, certainly some >> concerns over support for Spring 4 and OSGI. Our application is based on >> Spring DM (decision made a few years ago) however given the landscape as >> it >> is today I doubt whether we would have made the same decision. >> >> >> -- Peter Kriens pro Declarative services - DS is much better in working >> with services than Blueprint/Spring DM since they tend to to want to >> "hide" >> the dynamicity >> http://stackoverflow.com/questions/10008786/osgi-blueprint-vs-spring-dm >> >> -- Spring and OSGI >> http://karaf.922171.n3.nabble.com/OSGI-and-Spring-td4033211.html#a4033254 >> >> -- Spring and OSGI >> http://karaf.922171.n3.nabble.com/Re-The-future-of-the-Spring-with-Fabric8-td4033455.html >> >> -- We should also make clear that Spring DM is dead. And that in general >> Spring on OSGi is not a good idea >> https://github.com/fabric8io/fabric8/issues/1634 >> >> -- Spring stops creating OSGI bundles >> http://stackoverflow.com/questions/21181154/where-can-i-find-spring-4-osgi-bundles >> http://www.eclipse.org/forums/index.php/t/513222/ >> >> -- Spring 4 + Gemini incompatibility >> https://www.eclipse.org/forums/index.php/t/642416/ >> >> -- I would be really careful with Gemini blueprint. Springsource seems to >> have completely abondoned OSGi. >> -- So I fear that Gemini blueprint will go the same way as spring dm which >> is not maintained at all >> http://stackoverflow.com/questions/20993870/most-suitable-osgi-platform/21013910#21013910 >> >> -- I somehow doubt that gemini blueprint is still active. See >> git.eclipse.org/c/gemini.blueprint/… >> -- Not sure how active aries blueprint is. >> http://stackoverflow.com/questions/22381205/osgi-declarative-services-and-spring >> >> >> >> >> -- >> View this message in context: >> http://karaf.922171.n3.nabble.com/Spring-vs-Blueprint-tp4035374p4035389.html >> Sent from the Karaf - User mailing list archive at Nabble.com. >> > >
