Re: Aries and Spring Co-Existance in Karaf
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
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 rocketra...@gmail.com 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
Re: Aries and Spring Co-Existance in Karaf
My point wasn't the technology across bundles -- rather, I'm talking about interop with the DI framework used *within* a bundle. For example, I may want to use Guice for DI within my bundle, but use Blueprint to expose/consume OSGi services. As it stands, developers have to learn each DI framework's own mechanisms for exposing/consuming services, which means additional complexity, potential compatibility issues (e.g. Spring proxies), and differing maturity of implementation (for example, if my DI framework of choice is Guice, I'm stuck with an immature Peaberry micro-services implementation). -- Raman Gupta VIVO Systems http://vivosys.com On 11/01/2011 09:01 AM, Guillaume Nodet wrote: 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 rocketra...@gmail.com mailto:rocketra...@gmail.com 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
Re: Aries and Spring Co-Existance in Karaf
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] ml-node+s922171n3470594...@n3.nabble.com To: mikevan mvangeert...@comcast.net 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 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-tp3438050p3470758.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Aries and Spring Co-Existance in Karaf
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. I believe Eclipse Gemini (AKA Spring DM 2.x) *can* mix and match Spring and Blueprint namespaces. There is an example shown here: http://static.springsource.org/osgi/docs/2.0.0.M1/reference/html-single/#blueprint:differences:xml However, Karaf doesn't support DM 2 / Gemini at this time AFAIK. -- Raman Gupta VIVO Systems http://vivosys.com
Re: Aries and Spring Co-Existance in Karaf
I think you are reading this wrong. Table 5.1. XML Configuration Differences On Nov 1, 2011, at 8:15 AM, Raman Gupta wrote: 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. I believe Eclipse Gemini (AKA Spring DM 2.x) *can* mix and match Spring and Blueprint namespaces. There is an example shown here: http://static.springsource.org/osgi/docs/2.0.0.M1/reference/html-single/#blueprint:differences:xml However, Karaf doesn't support DM 2 / Gemini at this time AFAIK. -- Raman Gupta VIVO Systems http://vivosys.com
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] ml-node+s922171n3470594...@n3.nabble.com To: mikevan mvangeert...@comcast.net 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 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-tp3438050p3470758.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Aries and Spring Co-Existance in Karaf
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.
Re: Aries and Spring Co-Existance in Karaf
On 11/01/2011 10:27 AM, Johan Edstrom wrote: I think you are reading this wrong. Table 5.1. XML Configuration Differences No. Scroll down to the end of that section. As mentioned before, in Spring DM one can mix and match the namespaces: [...snip...] The example above, uses the Spring beans, util, p, Spring Expression Language (SpEL) and the task namespace introduced in Spring 3.x, and Spring DM [ed: this should say Blueprint] namespace. -- Raman Gupta VIVO Systems http://vivosys.com
Re: Aries and Spring Co-Existance in Karaf
On 11/01/2011 10:30 AM, mikevan wrote: Why can't Gemini work in Karaf? You're right. I don't know if it will work. I should have said it doesn't work out of the box. If you decide to try it and get it working I'd be interested in your features.xml. I too have used Virgo extensively but have decided to move to Karaf for my current project. But I'd definitely like to see Gemini on Karaf. I believe your other scenario (camel, blueprint, spring contexts in the same bundle) is not possible with Aries Blueprint, but is possible with Gemini Blueprint. -- Raman Gupta VIVO Systems http://vivosys.com
Re: Aries and Spring Co-Existance in Karaf
Raman, Can you describe the technical reason why you couldn't use camel, aries, and gemini contexts in the same bundle? To my knowledge, aries and gemini both leverage the osgi interfaces for osgi stuff. So, as long as the service is consumed by the same context used by camel, shouldn't they work? - Original Message - From: Raman Gupta [via Karaf] ml-node+s922171n3470927...@n3.nabble.com To: mikevan mvangeert...@comcast.net Sent: Tuesday, November 1, 2011 11:06:36 AM Subject: Re: Aries and Spring Co-Existance in Karaf On 11/01/2011 10:30 AM, mikevan wrote: Why can't Gemini work in Karaf? You're right. I don't know if it will work. I should have said it doesn't work out of the box. If you decide to try it and get it working I'd be interested in your features.xml. I too have used Virgo extensively but have decided to move to Karaf for my current project. But I'd definitely like to see Gemini on Karaf. I believe your other scenario (camel, blueprint, spring contexts in the same bundle) is not possible with Aries Blueprint, but is possible with Gemini Blueprint. -- Raman Gupta VIVO Systems http://vivosys.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-tp3438050p3470927.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-tp3438050p3470974.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Aries and Spring Co-Existance in Karaf
Gotcha, that still would be an effect of the authors of Spring DM2 having the legacy schemas, I don;t really personally see why aries should support spring syntax if the standards agreed on one schema. Just my 0.2 though. /je On Nov 1, 2011, at 8:33 AM, Raman Gupta wrote: On 11/01/2011 10:27 AM, Johan Edstrom wrote: I think you are reading this wrong. Table 5.1. XML Configuration Differences No. Scroll down to the end of that section. As mentioned before, in Spring DM one can mix and match the namespaces: [...snip...] The example above, uses the Spring beans, util, p, Spring Expression Language (SpEL) and the task namespace introduced in Spring 3.x, and Spring DM [ed: this should say Blueprint] namespace. -- Raman Gupta VIVO Systems http://vivosys.com
Re: Aries and Spring Co-Existance in Karaf
I'm not at all a spring expert but I think people are being unclear about exactly what they are trying to do. There are a lot of capabilities in spring products and being very specific about exactly what you want might help clear things up. -- you can only use one blueprint implementation within one bundle (either the aries or the eclipse/spring one). (similarly for jpa, jta, ...) -- as long as all types of framework used within a bundle communicate cross-framework only through osgi services there should be no problem using as many frameworks as you want. But if, for example, some spring web object directly uses a blueprint component that isn't a service that almost certainly ties the spring web stuff to the spring blueprint implementation. As a separate issue, virgo has isolation between kernel and application code and karaf doesn't. I'm looking into implementing this in karaf using the same code (regions) as virgo uses (this is also the basis of the subsystems isolation code under development in aries) but at best this will only work in karaf trunk. This may or may not be important to any particular project. thanks david jencks On Nov 1, 2011, at 8:25 AM, mikevan wrote: Raman, Can you describe the technical reason why you couldn't use camel, aries, and gemini contexts in the same bundle? To my knowledge, aries and gemini both leverage the osgi interfaces for osgi stuff. So, as long as the service is consumed by the same context used by camel, shouldn't they work? - Original Message - From: Raman Gupta [via Karaf] ml-node+s922171n3470927...@n3.nabble.com To: mikevan mvangeert...@comcast.net Sent: Tuesday, November 1, 2011 11:06:36 AM Subject: Re: Aries and Spring Co-Existance in Karaf On 11/01/2011 10:30 AM, mikevan wrote: Why can't Gemini work in Karaf? You're right. I don't know if it will work. I should have said it doesn't work out of the box. If you decide to try it and get it working I'd be interested in your features.xml. I too have used Virgo extensively but have decided to move to Karaf for my current project. But I'd definitely like to see Gemini on Karaf. I believe your other scenario (camel, blueprint, spring contexts in the same bundle) is not possible with Aries Blueprint, but is possible with Gemini Blueprint. -- Raman Gupta VIVO Systems http://vivosys.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-tp3438050p3470927.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-tp3438050p3470974.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Aries and Spring Co-Existance in Karaf
David, When I read the early-release of the OSGi Service Platform Spec that contained the Subsystem Specification, I gotta admin, I got pretty excited. I like the ability to group a set of bundles into a subsystem , and then to control the visibility of packages both within the subsystem and external to the subsystem. When we talk about deploying a Karaf-managed application (a set of subsystems and the core karaf bundles) into a virtual machine, the ability to pick and choose the specific subsystems to deploy will make things like thread-management and cpu utilization easier. While the karaf features provisioning mechanism provides a grouping and deployment mechanism, there is no way to define the visibility of packages outside of a feature. Either a package is available to everyone, or it is available to no-one. A subsystem provisioning mechanism that allows for this control of visibility will in all likelihood allow us to solve a number of problems that karaf users are currently faced with. When thinking this through, I wonder if provisioning should be handled by Felix instead of Karaf? Felix is a service platform, and will need to implement its own provisioning capability at some point. Does it make sense to continue keeping it in karaf? I know this is thinking about something that may not take place for a while (maybe 6 months to a year), but I do think we should start looking into it. - Original Message - From: David Jencks [via Karaf] ml-node+s922171n3471177...@n3.nabble.com To: mikevan mvangeert...@comcast.net Sent: Tuesday, November 1, 2011 12:39:47 PM Subject: Re: Aries and Spring Co-Existance in Karaf I'm not at all a spring expert but I think people are being unclear about exactly what they are trying to do. There are a lot of capabilities in spring products and being very specific about exactly what you want might help clear things up. -- you can only use one blueprint implementation within one bundle (either the aries or the eclipse/spring one). (similarly for jpa, jta, ...) -- as long as all types of framework used within a bundle communicate cross-framework only through osgi services there should be no problem using as many frameworks as you want. But if, for example, some spring web object directly uses a blueprint component that isn't a service that almost certainly ties the spring web stuff to the spring blueprint implementation. As a separate issue, virgo has isolation between kernel and application code and karaf doesn't. I'm looking into implementing this in karaf using the same code (regions) as virgo uses (this is also the basis of the subsystems isolation code under development in aries) but at best this will only work in karaf trunk. This may or may not be important to any particular project. thanks david jencks On Nov 1, 2011, at 8:25 AM, mikevan wrote: Raman, Can you describe the technical reason why you couldn't use camel, aries, and gemini contexts in the same bundle? To my knowledge, aries and gemini both leverage the osgi interfaces for osgi stuff. So, as long as the service is consumed by the same context used by camel, shouldn't they work? - Original Message - From: Raman Gupta [via Karaf] [hidden email] To: mikevan [hidden email] Sent: Tuesday, November 1, 2011 11:06:36 AM Subject: Re: Aries and Spring Co-Existance in Karaf On 11/01/2011 10:30 AM, mikevan wrote: Why can't Gemini work in Karaf? You're right. I don't know if it will work. I should have said it doesn't work out of the box. If you decide to try it and get it working I'd be interested in your features.xml. I too have used Virgo extensively but have decided to move to Karaf for my current project. But I'd definitely like to see Gemini on Karaf. I believe your other scenario (camel, blueprint, spring contexts in the same bundle) is not possible with Aries Blueprint, but is possible with Gemini Blueprint. -- Raman Gupta VIVO Systems http://vivosys.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-tp3438050p3470927.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-tp3438050p3470974.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-tp3438050p3471177.html To start a new topic under Karaf - User, email ml
Re: Aries and Spring Co-Existance in Karaf
On Nov 1, 2011, at 9:58 AM, mikevan wrote: David, When I read the early-release of the OSGi Service Platform Spec that contained the Subsystem Specification, I gotta admin, I got pretty excited. I like the ability to group a set of bundles into a subsystem , and then to control the visibility of packages both within the subsystem and external to the subsystem. When we talk about deploying a Karaf-managed application (a set of subsystems and the core karaf bundles) into a virtual machine, the ability to pick and choose the specific subsystems to deploy will make things like thread-management and cpu utilization easier. While the karaf features provisioning mechanism provides a grouping and deployment mechanism, there is no way to define the visibility of packages outside of a feature. Either a package is available to everyone, or it is available to no-one. A subsystem provisioning mechanism that allows for this control of visibility will in all likelihood allow us to solve a number of problems that karaf users are currently faced with. That seems likely. What I'm slightly uncomfortable with in (my understanding of) the subsystem spec is that it ties a region (set of bundles with restricted visibility to other regions) to a subsystem (either feature, composite, or application) which has fairly fixed content. I'm afraid this is going to be too restrictive and that most people may want to set up a few regions with specified visibility to other regions and then start deploying sets of bundles (karaf features) into specific regions. This seems to me like a more flexible point of view. Anyway this is what I'm implementing and maybe we can see if people like it. This will also give people a chance to experiment with isolation before the spec is out. When thinking this through, I wonder if provisioning should be handled by Felix instead of Karaf? Felix is a service platform, and will need to implement its own provisioning capability at some point. Does it make sense to continue keeping it in karaf? I know this is thinking about something that may not take place for a while (maybe 6 months to a year), but I do think we should start looking into it. I'm not sure exactly what you mean by provisioning. Aries is developing the subsystem RI on top of the eclipse regions jar. My understanding of the subsystem spec is that a subsystem has an application manifest that lists the bundles you are sure you want in the subsystem, and then a deployment manifest is generated that also includes all the other bundles needed to make it work. I think this uses OBR (possibly a newer spec version than current felix obr implementation, I'm not sure). Then you deploy the subsystem from the deployment manifest, and it tells you where the bundles to install are. So from this point of view I'm not sure what parts of this are provisioning and how provisioning could be part of felix when the subsystems stuff is in aries. I'm always confused by what provisioning is maybe this time I'll find out :-) thanks david jencks - Original Message - From: David Jencks [via Karaf] ml-node+s922171n3471177...@n3.nabble.com To: mikevan mvangeert...@comcast.net Sent: Tuesday, November 1, 2011 12:39:47 PM Subject: Re: Aries and Spring Co-Existance in Karaf I'm not at all a spring expert but I think people are being unclear about exactly what they are trying to do. There are a lot of capabilities in spring products and being very specific about exactly what you want might help clear things up. -- you can only use one blueprint implementation within one bundle (either the aries or the eclipse/spring one). (similarly for jpa, jta, ...) -- as long as all types of framework used within a bundle communicate cross-framework only through osgi services there should be no problem using as many frameworks as you want. But if, for example, some spring web object directly uses a blueprint component that isn't a service that almost certainly ties the spring web stuff to the spring blueprint implementation. As a separate issue, virgo has isolation between kernel and application code and karaf doesn't. I'm looking into implementing this in karaf using the same code (regions) as virgo uses (this is also the basis of the subsystems isolation code under development in aries) but at best this will only work in karaf trunk. This may or may not be important to any particular project. thanks david jencks On Nov 1, 2011, at 8:25 AM, mikevan wrote: Raman, Can you describe the technical reason why you couldn't use camel, aries, and gemini contexts in the same bundle? To my knowledge, aries and gemini both leverage the osgi interfaces for osgi stuff. So, as long as the service is consumed by the same context used by camel, shouldn't they work? - Original Message
Re: Aries and Spring Co-Existance in Karaf
It creates a bp context. no. Depends. - SpringProxy issues comes to mind as well as glib usage. On Oct 20, 2011, at 9:31 AM, mikevan wrote: I have some questions about how Spring and Aries co-exist in Karaf. 1) If you have an application that uses aries blueprint, does aries blueprint create its own application context for bundles? 2) Can applications that rely heavily on spring annotations work inside of a blueprint environment? 3) Can a bundle using aries successfully wire to a bundle that uses springdm? - 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-tp3438050p3438050.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Aries and Spring Co-Existance in Karaf
A bundle that is activated by blueprint would not activate springs AnnotationProcessors, nor do I think they would work as you'd have no application context. Sure they publish/consume services. Spring relies heavily on proxies / cglib / aopalliance and whatnot-else, the actual implementation of say a Dao may be quite far from what you actually expect. Niether extender does more than try to publish / subscribe events from the osgi service-registry. You'd run into the same thing expecting Spring annotations to work magically in guice. /je On Oct 20, 2011, at 9:48 AM, mikevan wrote: Regarding question 2: I'm wondering why this would be the case. If you have a bundle that is activated by aries blueprint, and if that bundle then uses Spring annotations internally, wouldn't a spring context be created within the blueprint context? If this is true, then wouldn't the annotations be usable? If not, this seems like a strong use-case against migration to blueprint for bundles that use spring annotations. Regarding question 3: Doesn't the underlying OSGi framework manage wiring? I understand that both Aries and SpringDM have thier own extender bundles that appear to manage wiring, but don't they both leverage the wiring capability of the underlying framework? If so, wouldn't the extenders share wiring information based on the underlying framework's wiring mechanism? Johan Edstrom-2 wrote: It creates a bp context. no. Depends. - SpringProxy issues comes to mind as well as glib usage. On Oct 20, 2011, at 9:31 AM, mikevan wrote: I have some questions about how Spring and Aries co-exist in Karaf. 1) If you have an application that uses aries blueprint, does aries blueprint create its own application context for bundles? 2) Can applications that rely heavily on spring annotations work inside of a blueprint environment? 3) Can a bundle using aries successfully wire to a bundle that uses springdm? - 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-tp3438050p3438050.html Sent from the Karaf - User mailing list archive at Nabble.com. - 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-tp3438050p3438104.html Sent from the Karaf - User mailing list archive at Nabble.com.
