2014-06-13 10:02 GMT+02:00 Charlie Mordant <cmorda...@gmail.com>: > As an addition, you can always use Spring beans with Aries-bp, as you > would do with any other bp bean. > > There are two big limitations in Aries that makes reusing spring beans difficult: * FactoryBean are not supported * type based discovery is not supported
So for beans that are somewhat tied to any spring api, it's not necessarily an easy task to migrate. > The only thing you cannot do without spring-dm/gemini is the use of Spring > namespaces/annotations. > Namespaces are supported by spring-dm/gemini afaik. > I'm pretty sure it's relatively easy to bridge annotation support > configuring the right Spring beans: I dropped my devs on it due to my > ignorance (5 years ago) on an OSGI-ready Spring classpath scanner > implementation. > > Best regards, > > > 2014-06-12 23:21 GMT+02:00 Krzysztof Sobkowiak <krzys.sobkow...@gmail.com> > : > > If many people still need a Spring integration with OSGi it should be no >> problem. ServiceMix Bundles sub-project provides now Spring bundles. We >> have also Eclipse Gemini Blueprint (successor of Spring DM), but I don't >> know how active the project is. But usage of Gemini for Spring integration >> forces usage of the Gemini's Blueprint implementation too. Personally I >> don't like such a configuration. I prefer usage of Spring DM which, I think >> so, doesn't need to die. Indeed it's died. But it can be reanimated and >> provide a lightweight Spring integration -- probably as a new project based >> on Spring DM code base. If people want (or need) to use Spring in OSGi >> there should be no problem. They must only invest some effort to make the >> Spring OSGi integration still living >> >> Best regards >> Krzysztof >> >> >> On 12.06.2014 22:57, Tim Jones wrote: >> >> I am adding a few URLs as I think it is will be of interest to others who are >> looking for direction re the future of Spring and OSGI >> >> -- Somehow I wonder how well future spring versions will behave in OSGi. I >> think we should start to at least warn our users that continued use of >> spring in OSGi is an increasing risk. >> http://karaf.922171.n3.nabble.com/Spring-OSGi-bundles-no-longer-being-released-td4031212.html >> >> -- Are we really going to let die the Spring integration with >> 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 >> ideahttps://github.com/fabric8io/fabric8/issues/1634 >> >> >> >> -- >> View this message in context: >> http://karaf.922171.n3.nabble.com/OSGI-and-Spring-tp4033211p4033485.html >> Sent from the Karaf - User mailing list archive at Nabble.com. >> >> >> >> -- >> Krzysztof Sobkowiak >> >> JEE & OSS Architect | Technical Architect @ Capgemini >> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center >> <http://www.pl.capgemini-sdm.com/> | Wroclaw >> e-mail: krzys.sobkow...@gmail.com | Twitter: @KSobkowiak >> Calendar: goo.gl/yvsebC >> > > > > -- > Charlie Mordant > > Full OSGI/EE stack made with Karaf: > https://github.com/OsgiliathEnterprise/net.osgiliath.parent >
