Sure, They in the end of the day are just beans? I.e the invocation of them or if say the spring-dm parser merges them if you had two spring context would be technical invocation details.
All that really happens is that when you load a bundle, an extender looks for OSGI-INF/blueprint/**.xml or META-INF/spring/**.xml For each file found, parse and start instantiating stuff inside of a "context", a context is just an object. /je On Nov 1, 2011, at 8:30 AM, mikevan wrote: > > > Johan, > > > > Then, the three contexts can work inside of the same bundle? > > > > ----- Original Message ----- > > > From: "Johan Edstrom-2 [via Karaf]" > <ml-node+s922171n3470819...@n3.nabble.com> > To: "mikevan" <mvangeert...@comcast.net> > Sent: Tuesday, November 1, 2011 10:29:38 AM > Subject: Re: Aries and Spring Co-Existance in Karaf > > If you use osgi services you can accomplish this. > > On Nov 1, 2011, at 8:06 AM, mikevan wrote: > > >> >> >> Guillaume, >> >> >> >> Consider the following use-case: >> >> 1) A bundle is activated by Aries Blueprint, and Blueprint consumes a osgi >> service that provides a jms connection. (configured in an OSGI-INF/blueprint >> directory) >> >> 2) The bundle uses spring-web to create a restful endpoint (configured in a >> META-INF/spring directory). >> >> 3) The bundle uses camel to route between the restful endpoint and the jms >> osgi service (the route is defined using java dsl). >> >> >> >> This example, while not depicting the most optimal usage of these >> technologies, is conceivable of something someone could try to do. As such, >> it is an example of a scenario where three different contexts (blueprint, >> camel, and spring) could be created. >> >> >> >> In this example, how would the three contexts work together? In my work, >> I've seen coding like this where Spring is desired, and where Aries >> blueprint doesn't provide the functionality Spring provides. In that >> environment, there is a movement towards Eclipse Gemini because it is >> written to play nicely with Spring. What I'd like to do is once and for >> all, identify if Aries and Spring can work in the same bundle or not. >> Normally what I hear is no, but from my prototyping, that response doesn't >> hold water. >> >> >> >> >> ----- Original Message ----- >> >> >> From: "Guillaume Nodet [via Karaf]" < [hidden email] > >> To: "mikevan" < [hidden email] > >> Sent: Tuesday, November 1, 2011 9:01:47 AM >> Subject: Re: Aries and Spring Co-Existance in Karaf >> >> You can use OSGi services for that. OSGi services can be exported and >> imported irrespective of the underlying technology used. >> >> >> On Tue, Nov 1, 2011 at 13:35, Raman Gupta < [hidden email] > wrote: >> >> >> >> On 11/01/2011 06:05 AM, Ioannis Canellos wrote: >>> Let's not confuse blueprint with spring. Blueprint is >>> a declarative way to work with OSGi services and Spring is a framework >>> for creating applications. >>> I don't think that Aries has the same focus with Spring but with SpringDM. >>> >>> You can always use both, if you have to go with Spring. >>> >>> If I had to use Spring, I would use it only where its necessary and >>> for managing services etc I would use Aries. >>> Example: >>> In Cellar 90% of the modules use Aries, but there is a single module >>> that uses Spring/SpringDM. We don't have any problem with that. >> >> What would have been nice is if Blueprint provided a way, out of the >> box, to expose beans created by Spring or Guice to the Blueprint >> context. That way, one could use the DI framework of choice / >> annotations inside a bundle, while consistently using Blueprint as a >> microservice layer. I'm surprised the Blueprint spec developers didn't >> consider interop with existing DI frameworks as a first class spec >> item. I suppose such functionality could still be implemented as a >> Blueprint extension for each DI framework. >> >> Regards, >> Raman Gupta >> VIVO Systems >> http://vivosys.com >> >> >> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> >> >> >> >> >> >> If you reply to this email, your message will be added to the discussion >> below: >> http://karaf.922171.n3.nabble.com/Aries-and-Spring-Co-Existance-in-Karaf-tp3438050p3470594.html >> >> To start a new topic under Karaf - User, email [hidden email] >> To unsubscribe from Karaf - User, click here . >> >> ----- >> Mike Van (All links open in new tabs) >> Committer - Kalumet >> >> Atraxia Technologies >> >> NCI Inc >> >> Mike Van's Open Source Technologies Blog >> -- >> View this message in context: >> http://karaf.922171.n3.nabble.com/Aries-and-Spring-Co-Existance-in-Karaf-tp3438050p3470758.html >> >> Sent from the Karaf - User mailing list archive at Nabble.com. > > > > > > If you reply to this email, your message will be added to the discussion > below: > http://karaf.922171.n3.nabble.com/Aries-and-Spring-Co-Existance-in-Karaf-tp3438050p3470819.html > > To start a new topic under Karaf - User, email > ml-node+s922171n930749...@n3.nabble.com > To unsubscribe from Karaf - User, click here . > > ----- > Mike Van (All links open in new tabs) > Committer - Kalumet > > Atraxia Technologies > > NCI Inc > > Mike Van's Open Source Technologies Blog > -- > View this message in context: > http://karaf.922171.n3.nabble.com/Aries-and-Spring-Co-Existance-in-Karaf-tp3438050p3470822.html > Sent from the Karaf - User mailing list archive at Nabble.com.
