You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Ioannis Canellos <io...@gmail.com> on 2011/11/01 11:05:36 UTC
Re: Aries and Spring Co-Existance in Karaf
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.
--
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>
**
Blog: http://iocanel.blogspot.com
**
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
Apache Gora <http://incubator.apache.org/gora/> Committer
*
Re: Aries and Spring Co-Existance in Karaf
Posted by David Jencks <da...@yahoo.com>.
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...@n3.nabble.com>
> To: "mikevan" <mv...@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-node+s922171n930749h71@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-tp3438050p3471232.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Aries and Spring Co-Existance in Karaf
Posted by mikevan <mv...@comcast.net>.
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...@n3.nabble.com>
To: "mikevan" <mv...@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-node+s922171n930749h71@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-tp3438050p3471232.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Aries and Spring Co-Existance in Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi all,
we can have different kind of issue:
- Gemini Blueprint and Aries blueprint share the same blueprint
namespace, that's why you can deploy both in the same container (or you
can have side effect)
- it's quite the same between JPA, JTA, etc as Gemini and Aries provide
OSGi services (without properties) to the same interface (for instance
the JPA entity manager). However, it could world with some minor enhancement
- we don't have issue between Spring DM and Aries because they don't use
the same namespace
My 0.02$
Regards
JB
On 11/01/2011 04:25 PM, 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...@n3.nabble.com>
> To: "mikevan"<mv...@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.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Aries and Spring Co-Existance in Karaf
Posted by David Jencks <da...@yahoo.com>.
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...@n3.nabble.com>
> To: "mikevan" <mv...@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+s922171n930749h71@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
Posted by mikevan <mv...@comcast.net>.
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...@n3.nabble.com>
To: "mikevan" <mv...@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+s922171n930749h71@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
Posted by Raman Gupta <ro...@gmail.com>.
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 <rocketraman@gmail.com
> <ma...@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
Posted by Raman Gupta <ro...@gmail.com>.
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
Posted by mikevan <mv...@comcast.net>.
Raman,
Thanks. But, honestly, that still doesn't answer the question. Why can't Gemini work in Karaf? Does it have code that is tied directly to another container (Virgo Kernel)? Or, is the issue that nobody has written a provisioning document for Gemini to work in Karaf? I believe that latter is the answer, not the former.
I understand the motivations for not using Spring and using Aries instead. However, I have yet to hear a good technical argument against using Karaf/Gemini. Please understand, I'm not trying to promote springsource or any consulting company. Rather, I'm trying to make sure that Karaf doesn't cut out a large group of users simply because of the notion that "spring bad, aries good". I've worked with Virgo kernel, and Karaf is superior to it. The only reason for intelligent folks to choose Virgo Kernel over Karaf is the argument that Karaf doesn't play well with Spring. I find this notion to be, at best, dubious.
Honestly, the Aries vs SpringDM (now Gemini) discussion sounds very similar to the JPA vs Hibernate discussion from last year. In that discussion, Hibernate was widely derided by the Karaf community with numerous folks stating that Hibernate simply couldn't work in Karaf. However, after a couple of days I was able to get Hibernate working just fine in Karaf. Before I make a decision about Aries or SpringDM (Gemini), I'd like to hear about folks' actual experiences instead of thier biases.
----- Original Message -----
From: "Raman Gupta [via Karaf]" <ml...@n3.nabble.com>
To: "mikevan" <mv...@comcast.net>
Sent: Tuesday, November 1, 2011 10:16:21 AM
Subject: 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
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-tp3438050p3470779.html
To start a new topic under Karaf - User, email ml-node+s922171n930749h71@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-tp3438050p3470821.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Aries and Spring Co-Existance in Karaf
Posted by Johan Edstrom <se...@gmail.com>.
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
Posted by Raman Gupta <ro...@gmail.com>.
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
Posted by Johan Edstrom <se...@gmail.com>.
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
Posted by Raman Gupta <ro...@gmail.com>.
> 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
Posted by Johan Edstrom <se...@gmail.com>.
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...@n3.nabble.com>
> To: "mikevan" <mv...@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+s922171n930749h71@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
Posted by mikevan <mv...@comcast.net>.
Johan,
Then, the three contexts can work inside of the same bundle?
----- Original Message -----
From: "Johan Edstrom-2 [via Karaf]" <ml...@n3.nabble.com>
To: "mikevan" <mv...@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+s922171n930749h71@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
Posted by Johan Edstrom <se...@gmail.com>.
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...@n3.nabble.com>
> To: "mikevan" <mv...@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+s922171n930749h71@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
Posted by mikevan <mv...@comcast.net>.
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...@n3.nabble.com>
To: "mikevan" <mv...@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+s922171n930749h71@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
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ro...@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
Posted by Raman Gupta <ro...@gmail.com>.
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