Can't you use Aries bean 'factory-ref' and 'init-method' to implement factorybeans? I knew that post processors weren't supported, but never faced the factorybean issue (maybe I didn't dealt with it).
2014-06-13 10:14 GMT+02:00 Guillaume Nodet <gno...@apache.org>: > > > > 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 >> > > -- Charlie Mordant Full OSGI/EE stack made with Karaf: https://github.com/OsgiliathEnterprise/net.osgiliath.parent
