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]" <[email protected]> To: "mikevan" <[email protected]> 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 [email protected] 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.
