You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by akuhtz <an...@gmail.com> on 2016/03/18 11:24:18 UTC
Blueprint or DS or what to use?
Hello,
I've an application running with spring-dm and because spring-dm is no
longer developed I'm looking for a replacement.
Now I'm confused because there was a shift in karaf (core) from blueprint to
DS and today I saw a post on the dev list, saying that DS does not support
as much as blueprint does.
As an end-user I would like to know what the proposed way to go is: DS or
blueprint, both or what else?
--
View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Blueprint or DS or what to use?
Posted by Tim Jones <ti...@mccarthy.co.nz>.
I realise rereading my post that it may have been a little ambiguous as to
which direction we have taken => we have decided that Declarative Services
will be the best solution for us long term.
--
View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045922.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Blueprint or DS or what to use?
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Tim,
On 21.03.2016 09:48, Timothy Ward wrote:
> Hi Christian,
>
>
>> On 21 Mar 2016, at 08:27, Christian Schneider
>> <chris@die-schneider.net <ma...@die-schneider.net>> wrote:
>>
>> Indeed it is difficult to predict where the OSGi community will go in
>> the future.
>
> I’m not sure that I agree with this. OSGi RFPs and RFCs are publicly
> available at https://github.com/osgi/design, and questions on the OSGi
> mailing lists get pretty comprehensive answers
> (https://www.osgi.org/community/mail-lists/). In this specific
> case, there are no OSGi members driving the Blueprint RFCs (RFCs 155,
> 156, 164 and 166) which is why they have had no activity since 2011 or so.
>
The OSGi community is more than the OSGi alliance. For example we at
Talend are also part of the OSGi community but as we unfortunately do
not get backing for an alliance membership none of our efforts will go
into a RFC. On the other hand I agree with you that DS gains more
traction at the moment. Guillaumes effort on the spring namespace
support for blueprint is a great development
on the blueprint side but there are not many other such examples.
>
>> - Services and Remoting can be solved by Remote Service Admin. With
>> ECF and Aries rsa (CXF-DOSGi) there are now two stacks available on
>> karaf that can help with this.
>
> There are also a lot of other RSA implementations which can be
> deployed in any OSGi framework.
I would like to see a lot more of these other implementations.
Unfortunately there is not much information on how to use them
especially on apache karaf. I think a major enabler is to find the
bundles on maven central. Another big part is the documentation and of
course the license.
So from the license side the Amdatu implementation would be interesting.
Maybe someone can do a tutorial for it?
Not sure about the others. Are they are all closed source?
>
>> Still it can be a little rough if you want to use some special CXF
>> features. We will have to prove using some good examples / pocs that
>> Remote Services can fully replace the blueprint CXF namespaces.
>>
>> Btw. I have some plans for Aries RSA to support application wide
>> policies. The idea is to define some common aspects of your services
>> centrally and apply them to all exported OSGi services. So for
>> example you could define in one central point that all your services
>> with JAXRS annotations should be auto exported and have single sign
>> on authentication using STS, SSL encryption and logging.
>
> This is configuration for the RSA distribution provider and should be
> possible to define at a central point for any RSA implementation, not
> just when using Karaf’s preferred CXF provider.
Yes. The way to specify this is configuration or more specific service
properties and additional properties. What I am refering to is that I
introduced an extension interface in Aries RSA that allows
to customize what the TopologyManager adds in form of additional
properties. See
https://github.com/apache/aries-rsa/blob/master/spi/src/main/java/org/apache/aries/rsa/spi/ExportPolicy.java
Probably other Remote Service Admin impls have similar ways to do this.
The other part of the solution of course is to then apply these
configurations in the provider for the RemoteServiceAdmin. CXF is just
an example here of course but it is the most widely used JAXWS and JAXRS
impl today and people do quite some fancy configs in blueprint today. So
to replicate this we have to make sure we can do the same using Remote
Service Admin. CXF DOSGi supports intents implemented by Features but I
think no one has tried to implement some of the more advanced security
setups with this.
>
>>
>> The migration though is still a big issue.
>>
>> Some time ago I did the migration of a medium sized production system
>> from servlet container + spring to karaf + blueprint. The big problem
>> there was that we had to do the transition
>> while the main team was going full steam and doing releases. It was
>> the start of the blueprint-maven-plugin as this was the only way to
>> do migration without a big bang. So if you
>> have to do this then the annotation based approach + the plugin above
>> can help a lot. If someone wants to try this I can help with some
>> good advices. If there is some interest I can also blog about
>> how to do such a transition in practice.
>>
>> A migration to DS will pretty much be a big bang as it is too
>> different from spring to do a smooth transition. I think it is
>> possible to do a full business application in DS but the migration
>> step is bigger.
>
> This is also incorrect - OSGi is a modular environment, and the whole
> point is that modules can be changed individually. Both DS and
> Blueprint communicate between bundles using OSGi services so there is
> no problem at all with having one bundle using DS while the other uses
> Blueprint. The migration from blueprint to DS can occur one bundle at
> a time, and does not have to be a big bang across the whole codebase.
That is also what I thought when starting the migration :-)
Unfortunately the codebase I had to deal with was not modular at all.
They simply used annotations to declare and consume beans all over the
application in a tightly coupled fashion. Most of these beans did not
even have an interface.
It was not possible for me to split this into modules that offer and
consume services without doing a big refactoring. At the start I tried
to propose some refactorings but they were rejected by the team
responsible to ship the business features as they feared that any
instability or delay would possibly cancel the whole project.
So what I did was to replicate the beans they used using blueprint beans
out of annotations and define blueprint contexts that also contained
some beans of dependency bundles. This was of course not a nice OSGi
like module system but it was able to reflect the actual code base.
Then after the initial OSGi migration was done and the production system
was on OSGi they peace by peace now do the modularization to nice OSGi
bundles with services but this effort is still not finished.
So yes .. you can do the OSGi migration in a bundle by bundle fashion if
the code base is well designed but I would not bet on this being the
case in any spring project.
Best regards
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Blueprint or DS or what to use?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Tim,
FYI, Guillaume was involved in the Blueprint specification (and he's
OSGi Alliance member via RedHat if I remember well).
Regards
JB
On 03/21/2016 09:48 AM, Timothy Ward wrote:
> Hi Christian,
>
>
>> On 21 Mar 2016, at 08:27, Christian Schneider <chris@die-schneider.net
>> <ma...@die-schneider.net>> wrote:
>>
>> Indeed it is difficult to predict where the OSGi community will go in
>> the future.
>
> I’m not sure that I agree with this. OSGi RFPs and RFCs are publicly
> available at https://github.com/osgi/design, and questions on the OSGi
> mailing lists get pretty comprehensive answers
> (https://www.osgi.org/community/mail-lists/). In this specific
> case, there are no OSGi members driving the Blueprint RFCs (RFCs 155,
> 156, 164 and 166) which is why they have had no activity since 2011 or so.
>
>>
>> For DS the situation is hopefully a little better today than at the
>> time I did the comparison.
>> - JPA can be solved today by using the Aries JPA and JPATemplate but
>> it is not standardized. The upcoming spec hopefully will improve this.
>
> Specifically RFC 221
> (https://github.com/osgi/design/tree/master/rfcs/rfc0221)
>
>> - Services and Remoting can be solved by Remote Service Admin. With
>> ECF and Aries rsa (CXF-DOSGi) there are now two stacks available on
>> karaf that can help with this.
>
> There are also a lot of other RSA implementations which can be deployed
> in any OSGi framework.
>
>> Still it can be a little rough if you want to use some special CXF
>> features. We will have to prove using some good examples / pocs that
>> Remote Services can fully replace the blueprint CXF namespaces.
>>
>> Btw. I have some plans for Aries RSA to support application wide
>> policies. The idea is to define some common aspects of your services
>> centrally and apply them to all exported OSGi services. So for example
>> you could define in one central point that all your services with
>> JAXRS annotations should be auto exported and have single sign on
>> authentication using STS, SSL encryption and logging.
>
> This is configuration for the RSA distribution provider and should be
> possible to define at a central point for any RSA implementation, not
> just when using Karaf’s preferred CXF provider.
>
>>
>> The migration though is still a big issue.
>>
>> Some time ago I did the migration of a medium sized production system
>> from servlet container + spring to karaf + blueprint. The big problem
>> there was that we had to do the transition
>> while the main team was going full steam and doing releases. It was
>> the start of the blueprint-maven-plugin as this was the only way to do
>> migration without a big bang. So if you
>> have to do this then the annotation based approach + the plugin above
>> can help a lot. If someone wants to try this I can help with some good
>> advices. If there is some interest I can also blog about
>> how to do such a transition in practice.
>>
>> A migration to DS will pretty much be a big bang as it is too
>> different from spring to do a smooth transition. I think it is
>> possible to do a full business application in DS but the migration
>> step is bigger.
>
> This is also incorrect - OSGi is a modular environment, and the whole
> point is that modules can be changed individually. Both DS and Blueprint
> communicate between bundles using OSGi services so there is no problem
> at all with having one bundle using DS while the other uses Blueprint.
> The migration from blueprint to DS can occur one bundle at a time, and
> does not have to be a big bang across the whole codebase.
>
> Regards,
>
> Tim
>
>>
>> Christian
>>
>> On 21.03.2016 02:24, Tim Jones wrote:
>>> Andreas you are crossing or about to cross a bridge we are crossing
>>> at the
>>> moment. We also have a SpringDM based application. It is 3+ years in
>>> production and so a change as large as moving away from SpringDM is very
>>> disruptive. For the most part we considered only Aries Blueprint vs DS.
>>> However as you can see from this post there are other alternatives, some
>>> fairly recent such as support for Spring namespaces in Aries Blueprint.
>>>
>>> For us the most significant points to consider were
>>>
>>> 1) Will there still be good support in 5-10 years (having been burnt
>>> once we
>>> don't want face the same issue again)
>>>
>>> 2) Where is the general OSGi community heading? Blueprint/DS/other. The
>>> first sentence of Tim Ward's post is something we thought significant.
>>> Something that has concerned me over the last couple of years is
>>> sometimes
>>> an alternative is suggested by needs some jiggery pokery to make it
>>> work, it
>>> doesn't have wide support, little documentation, often has bugs which
>>> led to
>>> a churn of releases. While it may be a cool, clever solution we
>>> aren't going
>>> to bet our production system on cool and clever only.
>>>
>>> 3) We are by and large glue coders and don't have the ability nor want to
>>> spend the time/resource building our own custom solutions, this is
>>> where I
>>> think Spring has suited us well until now. We tried to identify what
>>> offerings were available for the bits we needed e.g. JPA, JDBC,
>>> transactional control, Camel JMS, CXF. It is an opinion only, but
>>> from what
>>> I could see Blueprint offered the broadest support (see Christian's
>>> ecosystems-compared
>>> http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider).
>>>
>>> The big one for us was lack of JPA/JDBC/transactional control for DS,
>>> while
>>> there were some solutions we wanted something with a 'spec behind
>>> it'. This
>>> is currently been worked on at the moment
>>> (https://github.com/apache/aries/tree/trunk/tx-control) and I think
>>> it is a
>>> significant piece of work that will make DS a much more attractive
>>> proposition in the enterprise/applications space. Admittedly there is
>>> a risk
>>> in being new adopter however we think the risk is worth it in this case.
>>> Camel has a recent DS offering camel-scr (although I think there are some
>>> issues with it). Hopefully in time more libraries will offer DS
>>> support out
>>> of the box.
>>>
>>> 4) We are not yet sure we will be able to fully realise the pros of the
>>> service dynamics that DS offers vs Blueprint as although one of our
>>> goals is
>>> to be able to 'hot swap' bundles into a running system this may be
>>> harder to
>>> achieve than we had hoped. We currently do some limited hot swapping with
>>> our SpringDM system.
>>>
>>> 5) Perhaps counter intuitively of less importance to us was the
>>> actual ease
>>> of transition, Blueprint would almost certainly be easier to migrate
>>> to from
>>> SpringDM but we think that this is a one off cost that will be
>>> outweighed in
>>> the long term.
>>>
>>> Tim
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045892.html
>>> Sent from the Karaf - User mailing list archive at Nabble.com
>>> <http://nabble.com>.
>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Blueprint or DS or what to use?
Posted by Timothy Ward <ti...@paremus.com>.
Hi Christian,
> On 21 Mar 2016, at 08:27, Christian Schneider <ch...@die-schneider.net> wrote:
>
> Indeed it is difficult to predict where the OSGi community will go in the future.
I’m not sure that I agree with this. OSGi RFPs and RFCs are publicly available at https://github.com/osgi/design <https://github.com/osgi/design>, and questions on the OSGi mailing lists get pretty comprehensive answers (https://www.osgi.org/community/mail-lists/ <https://www.osgi.org/community/mail-lists/>). In this specific case, there are no OSGi members driving the Blueprint RFCs (RFCs 155, 156, 164 and 166) which is why they have had no activity since 2011 or so.
>
> For DS the situation is hopefully a little better today than at the time I did the comparison.
> - JPA can be solved today by using the Aries JPA and JPATemplate but it is not standardized. The upcoming spec hopefully will improve this.
Specifically RFC 221 (https://github.com/osgi/design/tree/master/rfcs/rfc0221 <https://github.com/osgi/design/tree/master/rfcs/rfc0221>)
> - Services and Remoting can be solved by Remote Service Admin. With ECF and Aries rsa (CXF-DOSGi) there are now two stacks available on karaf that can help with this.
There are also a lot of other RSA implementations which can be deployed in any OSGi framework.
> Still it can be a little rough if you want to use some special CXF features. We will have to prove using some good examples / pocs that Remote Services can fully replace the blueprint CXF namespaces.
>
> Btw. I have some plans for Aries RSA to support application wide policies. The idea is to define some common aspects of your services centrally and apply them to all exported OSGi services. So for example you could define in one central point that all your services with JAXRS annotations should be auto exported and have single sign on authentication using STS, SSL encryption and logging.
This is configuration for the RSA distribution provider and should be possible to define at a central point for any RSA implementation, not just when using Karaf’s preferred CXF provider.
>
> The migration though is still a big issue.
>
> Some time ago I did the migration of a medium sized production system from servlet container + spring to karaf + blueprint. The big problem there was that we had to do the transition
> while the main team was going full steam and doing releases. It was the start of the blueprint-maven-plugin as this was the only way to do migration without a big bang. So if you
> have to do this then the annotation based approach + the plugin above can help a lot. If someone wants to try this I can help with some good advices. If there is some interest I can also blog about
> how to do such a transition in practice.
>
> A migration to DS will pretty much be a big bang as it is too different from spring to do a smooth transition. I think it is possible to do a full business application in DS but the migration step is bigger.
This is also incorrect - OSGi is a modular environment, and the whole point is that modules can be changed individually. Both DS and Blueprint communicate between bundles using OSGi services so there is no problem at all with having one bundle using DS while the other uses Blueprint. The migration from blueprint to DS can occur one bundle at a time, and does not have to be a big bang across the whole codebase.
Regards,
Tim
>
> Christian
>
> On 21.03.2016 02:24, Tim Jones wrote:
>> Andreas you are crossing or about to cross a bridge we are crossing at the
>> moment. We also have a SpringDM based application. It is 3+ years in
>> production and so a change as large as moving away from SpringDM is very
>> disruptive. For the most part we considered only Aries Blueprint vs DS.
>> However as you can see from this post there are other alternatives, some
>> fairly recent such as support for Spring namespaces in Aries Blueprint.
>>
>> For us the most significant points to consider were
>>
>> 1) Will there still be good support in 5-10 years (having been burnt once we
>> don't want face the same issue again)
>>
>> 2) Where is the general OSGi community heading? Blueprint/DS/other. The
>> first sentence of Tim Ward's post is something we thought significant.
>> Something that has concerned me over the last couple of years is sometimes
>> an alternative is suggested by needs some jiggery pokery to make it work, it
>> doesn't have wide support, little documentation, often has bugs which led to
>> a churn of releases. While it may be a cool, clever solution we aren't going
>> to bet our production system on cool and clever only.
>>
>> 3) We are by and large glue coders and don't have the ability nor want to
>> spend the time/resource building our own custom solutions, this is where I
>> think Spring has suited us well until now. We tried to identify what
>> offerings were available for the bits we needed e.g. JPA, JDBC,
>> transactional control, Camel JMS, CXF. It is an opinion only, but from what
>> I could see Blueprint offered the broadest support (see Christian's
>> ecosystems-compared
>> http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider).
>>
>> The big one for us was lack of JPA/JDBC/transactional control for DS, while
>> there were some solutions we wanted something with a 'spec behind it'. This
>> is currently been worked on at the moment
>> (https://github.com/apache/aries/tree/trunk/tx-control) and I think it is a
>> significant piece of work that will make DS a much more attractive
>> proposition in the enterprise/applications space. Admittedly there is a risk
>> in being new adopter however we think the risk is worth it in this case.
>> Camel has a recent DS offering camel-scr (although I think there are some
>> issues with it). Hopefully in time more libraries will offer DS support out
>> of the box.
>>
>> 4) We are not yet sure we will be able to fully realise the pros of the
>> service dynamics that DS offers vs Blueprint as although one of our goals is
>> to be able to 'hot swap' bundles into a running system this may be harder to
>> achieve than we had hoped. We currently do some limited hot swapping with
>> our SpringDM system.
>>
>> 5) Perhaps counter intuitively of less importance to us was the actual ease
>> of transition, Blueprint would almost certainly be easier to migrate to from
>> SpringDM but we think that this is a one off cost that will be outweighed in
>> the long term.
>>
>> Tim
>>
>>
>>
>>
>>
>> --
>> View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045892.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: Blueprint or DS or what to use?
Posted by Achim Nierbeck <bc...@googlemail.com>.
If I might throw in another tech, which hasn't been talked of yet.
Another possibility would be to take a look at CDI, we have pax-cdi which
does a fair share of leveraging cdi stuff in osgi
and afaik someone from IBM started to work on something to have cdi 2.0 be
compatible to OSGi. Especially the dynamics.
Never the less pax-cdi does already work quite nicely with it, the only
drawback because the company initially working on the RFP 148 lost interest
in it, it never happend to be finished. Maybe this will change with the cdi
2.0 approach.
regards, Achim
2016-03-21 10:28 GMT+01:00 Richard Nicholson <pu...@me.com>:
> np
>
> > On 21 Mar 2016, at 09:25, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> >
> > Hi Richard,
> >
> > Thanks again for your help, much appreciate !
> >
> > Let me send a private e-mail to you (copy with people involved in the
> decision in my company).
> >
> > Thanks !
> > Regards
> > JB
> >
> > On 03/21/2016 10:20 AM, Richard Nicholson wrote:
> >> JB -
> >>
> >> As I directly offered to you during our discussion in 2015 - if I can
> help in any way please let me know. Myself and other OSGi Board Members are
> more than happy to help any company that is considering joining the OSGi
> Alliance.
> >>
> >> Best Wishes.
> >>
> >>
> >>> On 21 Mar 2016, at 09:04, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> >>>
> >>> Hi Richard,
> >>>
> >>> we already had discussion with the OSGi Alliance. Christian and I
> asked if it would be possible to work on specifications "outside" of our
> company first, as OpenSource guys. It seems very difficult, so now, we are
> discussing internally with our company.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On 03/21/2016 09:53 AM, Richard Nicholson wrote:
> >>>>
> >>>>> On 21 Mar 2016, at 08:27, Christian Schneider <
> chris@die-schneider.net> wrote:
> >>>>>
> >>>>> Indeed it is difficult to predict where the OSGi community will go
> in the future.
> >>>>
> >>>> No great mystery, no crystal ball need and easily addressable.
> >>>>
> >>>> Companies making profit out of the Karaf community (selling services
> wrapped around it, or training based upon it), also companies using Karaf
> based solutions in their production systems and worried about longevity,
> should both join the OSGi Alliance.
> >>>>
> >>>> Get involved, commit resources to drive forwards specifications that
> you want to see. That is how the Alliance operates. DS has moved forwards
> precisely because OSGi Alliance members have put the effort in to do this.
> >>>>
> >>>>>
> >>>>> For DS the situation is hopefully a little better today than at the
> time I did the comparison.
> >>>>> - JPA can be solved today by using the Aries JPA and JPATemplate but
> it is not standardized. The upcoming spec hopefully will improve this.
> >>>>> - Services and Remoting can be solved by Remote Service Admin. With
> ECF and Aries rsa (CXF-DOSGi) there are now two stacks available on karaf
> that can help with this.
> >>>>> Still it can be a little rough if you want to use some special CXF
> features. We will have to prove using some good examples / pocs that Remote
> Services can fully replace the blueprint CXF namespaces.
> >>>>>
> >>>>> Btw. I have some plans for Aries RSA to support application wide
> policies. The idea is to define some common aspects of your services
> centrally and apply them to all exported OSGi services. So for example you
> could define in one central point that all your services with JAXRS
> annotations should be auto exported and have single sign on authentication
> using STS, SSL encryption and logging.
> >>>>>
> >>>>> The migration though is still a big issue.
> >>>>>
> >>>>> Some time ago I did the migration of a medium sized production
> system from servlet container + spring to karaf + blueprint. The big
> problem there was that we had to do the transition
> >>>>> while the main team was going full steam and doing releases. It was
> the start of the blueprint-maven-plugin as this was the only way to do
> migration without a big bang. So if you
> >>>>> have to do this then the annotation based approach + the plugin
> above can help a lot. If someone wants to try this I can help with some
> good advices. If there is some interest I can also blog about
> >>>>> how to do such a transition in practice.
> >>>>>
> >>>>> A migration to DS will pretty much be a big bang as it is too
> different from spring to do a smooth transition. I think it is possible to
> do a full business application in DS but the migration step is bigger.
> >>>>>
> >>>>> Christian
> >>>>>
> >>>>> On 21.03.2016 02:24, Tim Jones wrote:
> >>>>>> Andreas you are crossing or about to cross a bridge we are crossing
> at the
> >>>>>> moment. We also have a SpringDM based application. It is 3+ years in
> >>>>>> production and so a change as large as moving away from SpringDM is
> very
> >>>>>> disruptive. For the most part we considered only Aries Blueprint vs
> DS.
> >>>>>> However as you can see from this post there are other alternatives,
> some
> >>>>>> fairly recent such as support for Spring namespaces in Aries
> Blueprint.
> >>>>>>
> >>>>>> For us the most significant points to consider were
> >>>>>>
> >>>>>> 1) Will there still be good support in 5-10 years (having been
> burnt once we
> >>>>>> don't want face the same issue again)
> >>>>>>
> >>>>>> 2) Where is the general OSGi community heading? Blueprint/DS/other.
> The
> >>>>>> first sentence of Tim Ward's post is something we thought
> significant.
> >>>>>> Something that has concerned me over the last couple of years is
> sometimes
> >>>>>> an alternative is suggested by needs some jiggery pokery to make it
> work, it
> >>>>>> doesn't have wide support, little documentation, often has bugs
> which led to
> >>>>>> a churn of releases. While it may be a cool, clever solution we
> aren't going
> >>>>>> to bet our production system on cool and clever only.
> >>>>>>
> >>>>>> 3) We are by and large glue coders and don't have the ability nor
> want to
> >>>>>> spend the time/resource building our own custom solutions, this is
> where I
> >>>>>> think Spring has suited us well until now. We tried to identify what
> >>>>>> offerings were available for the bits we needed e.g. JPA, JDBC,
> >>>>>> transactional control, Camel JMS, CXF. It is an opinion only, but
> from what
> >>>>>> I could see Blueprint offered the broadest support (see Christian's
> >>>>>> ecosystems-compared
> >>>>>>
> http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider
> ).
> >>>>>>
> >>>>>> The big one for us was lack of JPA/JDBC/transactional control for
> DS, while
> >>>>>> there were some solutions we wanted something with a 'spec behind
> it'. This
> >>>>>> is currently been worked on at the moment
> >>>>>> (https://github.com/apache/aries/tree/trunk/tx-control) and I
> think it is a
> >>>>>> significant piece of work that will make DS a much more attractive
> >>>>>> proposition in the enterprise/applications space. Admittedly there
> is a risk
> >>>>>> in being new adopter however we think the risk is worth it in this
> case.
> >>>>>> Camel has a recent DS offering camel-scr (although I think there
> are some
> >>>>>> issues with it). Hopefully in time more libraries will offer DS
> support out
> >>>>>> of the box.
> >>>>>>
> >>>>>> 4) We are not yet sure we will be able to fully realise the pros of
> the
> >>>>>> service dynamics that DS offers vs Blueprint as although one of our
> goals is
> >>>>>> to be able to 'hot swap' bundles into a running system this may be
> harder to
> >>>>>> achieve than we had hoped. We currently do some limited hot
> swapping with
> >>>>>> our SpringDM system.
> >>>>>>
> >>>>>> 5) Perhaps counter intuitively of less importance to us was the
> actual ease
> >>>>>> of transition, Blueprint would almost certainly be easier to
> migrate to from
> >>>>>> SpringDM but we think that this is a one off cost that will be
> outweighed in
> >>>>>> the long term.
> >>>>>>
> >>>>>> Tim
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> View this message in context:
> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045892.html
> >>>>>> Sent from the Karaf - User mailing list archive at Nabble.com.
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Christian Schneider
> >>>>> http://www.liquid-reality.de
> >>>>>
> >>>>> Open Source Architect
> >>>>> http://www.talend.com
> >>>>>
> >>>>
> >>>
> >>> --
> >>> Jean-Baptiste Onofré
> >>> jbonofre@apache.org
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >>
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
Software Architect / Project Manager / Scrum Master
Re: Blueprint or DS or what to use?
Posted by Richard Nicholson <pu...@me.com>.
np
> On 21 Mar 2016, at 09:25, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> Hi Richard,
>
> Thanks again for your help, much appreciate !
>
> Let me send a private e-mail to you (copy with people involved in the decision in my company).
>
> Thanks !
> Regards
> JB
>
> On 03/21/2016 10:20 AM, Richard Nicholson wrote:
>> JB -
>>
>> As I directly offered to you during our discussion in 2015 - if I can help in any way please let me know. Myself and other OSGi Board Members are more than happy to help any company that is considering joining the OSGi Alliance.
>>
>> Best Wishes.
>>
>>
>>> On 21 Mar 2016, at 09:04, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>>
>>> Hi Richard,
>>>
>>> we already had discussion with the OSGi Alliance. Christian and I asked if it would be possible to work on specifications "outside" of our company first, as OpenSource guys. It seems very difficult, so now, we are discussing internally with our company.
>>>
>>> Regards
>>> JB
>>>
>>> On 03/21/2016 09:53 AM, Richard Nicholson wrote:
>>>>
>>>>> On 21 Mar 2016, at 08:27, Christian Schneider <ch...@die-schneider.net> wrote:
>>>>>
>>>>> Indeed it is difficult to predict where the OSGi community will go in the future.
>>>>
>>>> No great mystery, no crystal ball need and easily addressable.
>>>>
>>>> Companies making profit out of the Karaf community (selling services wrapped around it, or training based upon it), also companies using Karaf based solutions in their production systems and worried about longevity, should both join the OSGi Alliance.
>>>>
>>>> Get involved, commit resources to drive forwards specifications that you want to see. That is how the Alliance operates. DS has moved forwards precisely because OSGi Alliance members have put the effort in to do this.
>>>>
>>>>>
>>>>> For DS the situation is hopefully a little better today than at the time I did the comparison.
>>>>> - JPA can be solved today by using the Aries JPA and JPATemplate but it is not standardized. The upcoming spec hopefully will improve this.
>>>>> - Services and Remoting can be solved by Remote Service Admin. With ECF and Aries rsa (CXF-DOSGi) there are now two stacks available on karaf that can help with this.
>>>>> Still it can be a little rough if you want to use some special CXF features. We will have to prove using some good examples / pocs that Remote Services can fully replace the blueprint CXF namespaces.
>>>>>
>>>>> Btw. I have some plans for Aries RSA to support application wide policies. The idea is to define some common aspects of your services centrally and apply them to all exported OSGi services. So for example you could define in one central point that all your services with JAXRS annotations should be auto exported and have single sign on authentication using STS, SSL encryption and logging.
>>>>>
>>>>> The migration though is still a big issue.
>>>>>
>>>>> Some time ago I did the migration of a medium sized production system from servlet container + spring to karaf + blueprint. The big problem there was that we had to do the transition
>>>>> while the main team was going full steam and doing releases. It was the start of the blueprint-maven-plugin as this was the only way to do migration without a big bang. So if you
>>>>> have to do this then the annotation based approach + the plugin above can help a lot. If someone wants to try this I can help with some good advices. If there is some interest I can also blog about
>>>>> how to do such a transition in practice.
>>>>>
>>>>> A migration to DS will pretty much be a big bang as it is too different from spring to do a smooth transition. I think it is possible to do a full business application in DS but the migration step is bigger.
>>>>>
>>>>> Christian
>>>>>
>>>>> On 21.03.2016 02:24, Tim Jones wrote:
>>>>>> Andreas you are crossing or about to cross a bridge we are crossing at the
>>>>>> moment. We also have a SpringDM based application. It is 3+ years in
>>>>>> production and so a change as large as moving away from SpringDM is very
>>>>>> disruptive. For the most part we considered only Aries Blueprint vs DS.
>>>>>> However as you can see from this post there are other alternatives, some
>>>>>> fairly recent such as support for Spring namespaces in Aries Blueprint.
>>>>>>
>>>>>> For us the most significant points to consider were
>>>>>>
>>>>>> 1) Will there still be good support in 5-10 years (having been burnt once we
>>>>>> don't want face the same issue again)
>>>>>>
>>>>>> 2) Where is the general OSGi community heading? Blueprint/DS/other. The
>>>>>> first sentence of Tim Ward's post is something we thought significant.
>>>>>> Something that has concerned me over the last couple of years is sometimes
>>>>>> an alternative is suggested by needs some jiggery pokery to make it work, it
>>>>>> doesn't have wide support, little documentation, often has bugs which led to
>>>>>> a churn of releases. While it may be a cool, clever solution we aren't going
>>>>>> to bet our production system on cool and clever only.
>>>>>>
>>>>>> 3) We are by and large glue coders and don't have the ability nor want to
>>>>>> spend the time/resource building our own custom solutions, this is where I
>>>>>> think Spring has suited us well until now. We tried to identify what
>>>>>> offerings were available for the bits we needed e.g. JPA, JDBC,
>>>>>> transactional control, Camel JMS, CXF. It is an opinion only, but from what
>>>>>> I could see Blueprint offered the broadest support (see Christian's
>>>>>> ecosystems-compared
>>>>>> http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider).
>>>>>>
>>>>>> The big one for us was lack of JPA/JDBC/transactional control for DS, while
>>>>>> there were some solutions we wanted something with a 'spec behind it'. This
>>>>>> is currently been worked on at the moment
>>>>>> (https://github.com/apache/aries/tree/trunk/tx-control) and I think it is a
>>>>>> significant piece of work that will make DS a much more attractive
>>>>>> proposition in the enterprise/applications space. Admittedly there is a risk
>>>>>> in being new adopter however we think the risk is worth it in this case.
>>>>>> Camel has a recent DS offering camel-scr (although I think there are some
>>>>>> issues with it). Hopefully in time more libraries will offer DS support out
>>>>>> of the box.
>>>>>>
>>>>>> 4) We are not yet sure we will be able to fully realise the pros of the
>>>>>> service dynamics that DS offers vs Blueprint as although one of our goals is
>>>>>> to be able to 'hot swap' bundles into a running system this may be harder to
>>>>>> achieve than we had hoped. We currently do some limited hot swapping with
>>>>>> our SpringDM system.
>>>>>>
>>>>>> 5) Perhaps counter intuitively of less importance to us was the actual ease
>>>>>> of transition, Blueprint would almost certainly be easier to migrate to from
>>>>>> SpringDM but we think that this is a one off cost that will be outweighed in
>>>>>> the long term.
>>>>>>
>>>>>> Tim
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045892.html
>>>>>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> --
>>>>> Christian Schneider
>>>>> http://www.liquid-reality.de
>>>>>
>>>>> Open Source Architect
>>>>> http://www.talend.com
>>>>>
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Blueprint or DS or what to use?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Richard,
Thanks again for your help, much appreciate !
Let me send a private e-mail to you (copy with people involved in the
decision in my company).
Thanks !
Regards
JB
On 03/21/2016 10:20 AM, Richard Nicholson wrote:
> JB -
>
> As I directly offered to you during our discussion in 2015 - if I can help in any way please let me know. Myself and other OSGi Board Members are more than happy to help any company that is considering joining the OSGi Alliance.
>
> Best Wishes.
>
>
>> On 21 Mar 2016, at 09:04, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>
>> Hi Richard,
>>
>> we already had discussion with the OSGi Alliance. Christian and I asked if it would be possible to work on specifications "outside" of our company first, as OpenSource guys. It seems very difficult, so now, we are discussing internally with our company.
>>
>> Regards
>> JB
>>
>> On 03/21/2016 09:53 AM, Richard Nicholson wrote:
>>>
>>>> On 21 Mar 2016, at 08:27, Christian Schneider <ch...@die-schneider.net> wrote:
>>>>
>>>> Indeed it is difficult to predict where the OSGi community will go in the future.
>>>
>>> No great mystery, no crystal ball need and easily addressable.
>>>
>>> Companies making profit out of the Karaf community (selling services wrapped around it, or training based upon it), also companies using Karaf based solutions in their production systems and worried about longevity, should both join the OSGi Alliance.
>>>
>>> Get involved, commit resources to drive forwards specifications that you want to see. That is how the Alliance operates. DS has moved forwards precisely because OSGi Alliance members have put the effort in to do this.
>>>
>>>>
>>>> For DS the situation is hopefully a little better today than at the time I did the comparison.
>>>> - JPA can be solved today by using the Aries JPA and JPATemplate but it is not standardized. The upcoming spec hopefully will improve this.
>>>> - Services and Remoting can be solved by Remote Service Admin. With ECF and Aries rsa (CXF-DOSGi) there are now two stacks available on karaf that can help with this.
>>>> Still it can be a little rough if you want to use some special CXF features. We will have to prove using some good examples / pocs that Remote Services can fully replace the blueprint CXF namespaces.
>>>>
>>>> Btw. I have some plans for Aries RSA to support application wide policies. The idea is to define some common aspects of your services centrally and apply them to all exported OSGi services. So for example you could define in one central point that all your services with JAXRS annotations should be auto exported and have single sign on authentication using STS, SSL encryption and logging.
>>>>
>>>> The migration though is still a big issue.
>>>>
>>>> Some time ago I did the migration of a medium sized production system from servlet container + spring to karaf + blueprint. The big problem there was that we had to do the transition
>>>> while the main team was going full steam and doing releases. It was the start of the blueprint-maven-plugin as this was the only way to do migration without a big bang. So if you
>>>> have to do this then the annotation based approach + the plugin above can help a lot. If someone wants to try this I can help with some good advices. If there is some interest I can also blog about
>>>> how to do such a transition in practice.
>>>>
>>>> A migration to DS will pretty much be a big bang as it is too different from spring to do a smooth transition. I think it is possible to do a full business application in DS but the migration step is bigger.
>>>>
>>>> Christian
>>>>
>>>> On 21.03.2016 02:24, Tim Jones wrote:
>>>>> Andreas you are crossing or about to cross a bridge we are crossing at the
>>>>> moment. We also have a SpringDM based application. It is 3+ years in
>>>>> production and so a change as large as moving away from SpringDM is very
>>>>> disruptive. For the most part we considered only Aries Blueprint vs DS.
>>>>> However as you can see from this post there are other alternatives, some
>>>>> fairly recent such as support for Spring namespaces in Aries Blueprint.
>>>>>
>>>>> For us the most significant points to consider were
>>>>>
>>>>> 1) Will there still be good support in 5-10 years (having been burnt once we
>>>>> don't want face the same issue again)
>>>>>
>>>>> 2) Where is the general OSGi community heading? Blueprint/DS/other. The
>>>>> first sentence of Tim Ward's post is something we thought significant.
>>>>> Something that has concerned me over the last couple of years is sometimes
>>>>> an alternative is suggested by needs some jiggery pokery to make it work, it
>>>>> doesn't have wide support, little documentation, often has bugs which led to
>>>>> a churn of releases. While it may be a cool, clever solution we aren't going
>>>>> to bet our production system on cool and clever only.
>>>>>
>>>>> 3) We are by and large glue coders and don't have the ability nor want to
>>>>> spend the time/resource building our own custom solutions, this is where I
>>>>> think Spring has suited us well until now. We tried to identify what
>>>>> offerings were available for the bits we needed e.g. JPA, JDBC,
>>>>> transactional control, Camel JMS, CXF. It is an opinion only, but from what
>>>>> I could see Blueprint offered the broadest support (see Christian's
>>>>> ecosystems-compared
>>>>> http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider).
>>>>>
>>>>> The big one for us was lack of JPA/JDBC/transactional control for DS, while
>>>>> there were some solutions we wanted something with a 'spec behind it'. This
>>>>> is currently been worked on at the moment
>>>>> (https://github.com/apache/aries/tree/trunk/tx-control) and I think it is a
>>>>> significant piece of work that will make DS a much more attractive
>>>>> proposition in the enterprise/applications space. Admittedly there is a risk
>>>>> in being new adopter however we think the risk is worth it in this case.
>>>>> Camel has a recent DS offering camel-scr (although I think there are some
>>>>> issues with it). Hopefully in time more libraries will offer DS support out
>>>>> of the box.
>>>>>
>>>>> 4) We are not yet sure we will be able to fully realise the pros of the
>>>>> service dynamics that DS offers vs Blueprint as although one of our goals is
>>>>> to be able to 'hot swap' bundles into a running system this may be harder to
>>>>> achieve than we had hoped. We currently do some limited hot swapping with
>>>>> our SpringDM system.
>>>>>
>>>>> 5) Perhaps counter intuitively of less importance to us was the actual ease
>>>>> of transition, Blueprint would almost certainly be easier to migrate to from
>>>>> SpringDM but we think that this is a one off cost that will be outweighed in
>>>>> the long term.
>>>>>
>>>>> Tim
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045892.html
>>>>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> http://www.talend.com
>>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Blueprint or DS or what to use?
Posted by Richard Nicholson <pu...@me.com>.
JB -
As I directly offered to you during our discussion in 2015 - if I can help in any way please let me know. Myself and other OSGi Board Members are more than happy to help any company that is considering joining the OSGi Alliance.
Best Wishes.
> On 21 Mar 2016, at 09:04, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> Hi Richard,
>
> we already had discussion with the OSGi Alliance. Christian and I asked if it would be possible to work on specifications "outside" of our company first, as OpenSource guys. It seems very difficult, so now, we are discussing internally with our company.
>
> Regards
> JB
>
> On 03/21/2016 09:53 AM, Richard Nicholson wrote:
>>
>>> On 21 Mar 2016, at 08:27, Christian Schneider <ch...@die-schneider.net> wrote:
>>>
>>> Indeed it is difficult to predict where the OSGi community will go in the future.
>>
>> No great mystery, no crystal ball need and easily addressable.
>>
>> Companies making profit out of the Karaf community (selling services wrapped around it, or training based upon it), also companies using Karaf based solutions in their production systems and worried about longevity, should both join the OSGi Alliance.
>>
>> Get involved, commit resources to drive forwards specifications that you want to see. That is how the Alliance operates. DS has moved forwards precisely because OSGi Alliance members have put the effort in to do this.
>>
>>>
>>> For DS the situation is hopefully a little better today than at the time I did the comparison.
>>> - JPA can be solved today by using the Aries JPA and JPATemplate but it is not standardized. The upcoming spec hopefully will improve this.
>>> - Services and Remoting can be solved by Remote Service Admin. With ECF and Aries rsa (CXF-DOSGi) there are now two stacks available on karaf that can help with this.
>>> Still it can be a little rough if you want to use some special CXF features. We will have to prove using some good examples / pocs that Remote Services can fully replace the blueprint CXF namespaces.
>>>
>>> Btw. I have some plans for Aries RSA to support application wide policies. The idea is to define some common aspects of your services centrally and apply them to all exported OSGi services. So for example you could define in one central point that all your services with JAXRS annotations should be auto exported and have single sign on authentication using STS, SSL encryption and logging.
>>>
>>> The migration though is still a big issue.
>>>
>>> Some time ago I did the migration of a medium sized production system from servlet container + spring to karaf + blueprint. The big problem there was that we had to do the transition
>>> while the main team was going full steam and doing releases. It was the start of the blueprint-maven-plugin as this was the only way to do migration without a big bang. So if you
>>> have to do this then the annotation based approach + the plugin above can help a lot. If someone wants to try this I can help with some good advices. If there is some interest I can also blog about
>>> how to do such a transition in practice.
>>>
>>> A migration to DS will pretty much be a big bang as it is too different from spring to do a smooth transition. I think it is possible to do a full business application in DS but the migration step is bigger.
>>>
>>> Christian
>>>
>>> On 21.03.2016 02:24, Tim Jones wrote:
>>>> Andreas you are crossing or about to cross a bridge we are crossing at the
>>>> moment. We also have a SpringDM based application. It is 3+ years in
>>>> production and so a change as large as moving away from SpringDM is very
>>>> disruptive. For the most part we considered only Aries Blueprint vs DS.
>>>> However as you can see from this post there are other alternatives, some
>>>> fairly recent such as support for Spring namespaces in Aries Blueprint.
>>>>
>>>> For us the most significant points to consider were
>>>>
>>>> 1) Will there still be good support in 5-10 years (having been burnt once we
>>>> don't want face the same issue again)
>>>>
>>>> 2) Where is the general OSGi community heading? Blueprint/DS/other. The
>>>> first sentence of Tim Ward's post is something we thought significant.
>>>> Something that has concerned me over the last couple of years is sometimes
>>>> an alternative is suggested by needs some jiggery pokery to make it work, it
>>>> doesn't have wide support, little documentation, often has bugs which led to
>>>> a churn of releases. While it may be a cool, clever solution we aren't going
>>>> to bet our production system on cool and clever only.
>>>>
>>>> 3) We are by and large glue coders and don't have the ability nor want to
>>>> spend the time/resource building our own custom solutions, this is where I
>>>> think Spring has suited us well until now. We tried to identify what
>>>> offerings were available for the bits we needed e.g. JPA, JDBC,
>>>> transactional control, Camel JMS, CXF. It is an opinion only, but from what
>>>> I could see Blueprint offered the broadest support (see Christian's
>>>> ecosystems-compared
>>>> http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider).
>>>>
>>>> The big one for us was lack of JPA/JDBC/transactional control for DS, while
>>>> there were some solutions we wanted something with a 'spec behind it'. This
>>>> is currently been worked on at the moment
>>>> (https://github.com/apache/aries/tree/trunk/tx-control) and I think it is a
>>>> significant piece of work that will make DS a much more attractive
>>>> proposition in the enterprise/applications space. Admittedly there is a risk
>>>> in being new adopter however we think the risk is worth it in this case.
>>>> Camel has a recent DS offering camel-scr (although I think there are some
>>>> issues with it). Hopefully in time more libraries will offer DS support out
>>>> of the box.
>>>>
>>>> 4) We are not yet sure we will be able to fully realise the pros of the
>>>> service dynamics that DS offers vs Blueprint as although one of our goals is
>>>> to be able to 'hot swap' bundles into a running system this may be harder to
>>>> achieve than we had hoped. We currently do some limited hot swapping with
>>>> our SpringDM system.
>>>>
>>>> 5) Perhaps counter intuitively of less importance to us was the actual ease
>>>> of transition, Blueprint would almost certainly be easier to migrate to from
>>>> SpringDM but we think that this is a one off cost that will be outweighed in
>>>> the long term.
>>>>
>>>> Tim
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045892.html
>>>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Blueprint or DS or what to use?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Richard,
we already had discussion with the OSGi Alliance. Christian and I asked
if it would be possible to work on specifications "outside" of our
company first, as OpenSource guys. It seems very difficult, so now, we
are discussing internally with our company.
Regards
JB
On 03/21/2016 09:53 AM, Richard Nicholson wrote:
>
>> On 21 Mar 2016, at 08:27, Christian Schneider <ch...@die-schneider.net> wrote:
>>
>> Indeed it is difficult to predict where the OSGi community will go in the future.
>
> No great mystery, no crystal ball need and easily addressable.
>
> Companies making profit out of the Karaf community (selling services wrapped around it, or training based upon it), also companies using Karaf based solutions in their production systems and worried about longevity, should both join the OSGi Alliance.
>
> Get involved, commit resources to drive forwards specifications that you want to see. That is how the Alliance operates. DS has moved forwards precisely because OSGi Alliance members have put the effort in to do this.
>
>>
>> For DS the situation is hopefully a little better today than at the time I did the comparison.
>> - JPA can be solved today by using the Aries JPA and JPATemplate but it is not standardized. The upcoming spec hopefully will improve this.
>> - Services and Remoting can be solved by Remote Service Admin. With ECF and Aries rsa (CXF-DOSGi) there are now two stacks available on karaf that can help with this.
>> Still it can be a little rough if you want to use some special CXF features. We will have to prove using some good examples / pocs that Remote Services can fully replace the blueprint CXF namespaces.
>>
>> Btw. I have some plans for Aries RSA to support application wide policies. The idea is to define some common aspects of your services centrally and apply them to all exported OSGi services. So for example you could define in one central point that all your services with JAXRS annotations should be auto exported and have single sign on authentication using STS, SSL encryption and logging.
>>
>> The migration though is still a big issue.
>>
>> Some time ago I did the migration of a medium sized production system from servlet container + spring to karaf + blueprint. The big problem there was that we had to do the transition
>> while the main team was going full steam and doing releases. It was the start of the blueprint-maven-plugin as this was the only way to do migration without a big bang. So if you
>> have to do this then the annotation based approach + the plugin above can help a lot. If someone wants to try this I can help with some good advices. If there is some interest I can also blog about
>> how to do such a transition in practice.
>>
>> A migration to DS will pretty much be a big bang as it is too different from spring to do a smooth transition. I think it is possible to do a full business application in DS but the migration step is bigger.
>>
>> Christian
>>
>> On 21.03.2016 02:24, Tim Jones wrote:
>>> Andreas you are crossing or about to cross a bridge we are crossing at the
>>> moment. We also have a SpringDM based application. It is 3+ years in
>>> production and so a change as large as moving away from SpringDM is very
>>> disruptive. For the most part we considered only Aries Blueprint vs DS.
>>> However as you can see from this post there are other alternatives, some
>>> fairly recent such as support for Spring namespaces in Aries Blueprint.
>>>
>>> For us the most significant points to consider were
>>>
>>> 1) Will there still be good support in 5-10 years (having been burnt once we
>>> don't want face the same issue again)
>>>
>>> 2) Where is the general OSGi community heading? Blueprint/DS/other. The
>>> first sentence of Tim Ward's post is something we thought significant.
>>> Something that has concerned me over the last couple of years is sometimes
>>> an alternative is suggested by needs some jiggery pokery to make it work, it
>>> doesn't have wide support, little documentation, often has bugs which led to
>>> a churn of releases. While it may be a cool, clever solution we aren't going
>>> to bet our production system on cool and clever only.
>>>
>>> 3) We are by and large glue coders and don't have the ability nor want to
>>> spend the time/resource building our own custom solutions, this is where I
>>> think Spring has suited us well until now. We tried to identify what
>>> offerings were available for the bits we needed e.g. JPA, JDBC,
>>> transactional control, Camel JMS, CXF. It is an opinion only, but from what
>>> I could see Blueprint offered the broadest support (see Christian's
>>> ecosystems-compared
>>> http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider).
>>>
>>> The big one for us was lack of JPA/JDBC/transactional control for DS, while
>>> there were some solutions we wanted something with a 'spec behind it'. This
>>> is currently been worked on at the moment
>>> (https://github.com/apache/aries/tree/trunk/tx-control) and I think it is a
>>> significant piece of work that will make DS a much more attractive
>>> proposition in the enterprise/applications space. Admittedly there is a risk
>>> in being new adopter however we think the risk is worth it in this case.
>>> Camel has a recent DS offering camel-scr (although I think there are some
>>> issues with it). Hopefully in time more libraries will offer DS support out
>>> of the box.
>>>
>>> 4) We are not yet sure we will be able to fully realise the pros of the
>>> service dynamics that DS offers vs Blueprint as although one of our goals is
>>> to be able to 'hot swap' bundles into a running system this may be harder to
>>> achieve than we had hoped. We currently do some limited hot swapping with
>>> our SpringDM system.
>>>
>>> 5) Perhaps counter intuitively of less importance to us was the actual ease
>>> of transition, Blueprint would almost certainly be easier to migrate to from
>>> SpringDM but we think that this is a one off cost that will be outweighed in
>>> the long term.
>>>
>>> Tim
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045892.html
>>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Blueprint or DS or what to use?
Posted by Richard Nicholson <pu...@me.com>.
> On 21 Mar 2016, at 08:27, Christian Schneider <ch...@die-schneider.net> wrote:
>
> Indeed it is difficult to predict where the OSGi community will go in the future.
No great mystery, no crystal ball need and easily addressable.
Companies making profit out of the Karaf community (selling services wrapped around it, or training based upon it), also companies using Karaf based solutions in their production systems and worried about longevity, should both join the OSGi Alliance.
Get involved, commit resources to drive forwards specifications that you want to see. That is how the Alliance operates. DS has moved forwards precisely because OSGi Alliance members have put the effort in to do this.
>
> For DS the situation is hopefully a little better today than at the time I did the comparison.
> - JPA can be solved today by using the Aries JPA and JPATemplate but it is not standardized. The upcoming spec hopefully will improve this.
> - Services and Remoting can be solved by Remote Service Admin. With ECF and Aries rsa (CXF-DOSGi) there are now two stacks available on karaf that can help with this.
> Still it can be a little rough if you want to use some special CXF features. We will have to prove using some good examples / pocs that Remote Services can fully replace the blueprint CXF namespaces.
>
> Btw. I have some plans for Aries RSA to support application wide policies. The idea is to define some common aspects of your services centrally and apply them to all exported OSGi services. So for example you could define in one central point that all your services with JAXRS annotations should be auto exported and have single sign on authentication using STS, SSL encryption and logging.
>
> The migration though is still a big issue.
>
> Some time ago I did the migration of a medium sized production system from servlet container + spring to karaf + blueprint. The big problem there was that we had to do the transition
> while the main team was going full steam and doing releases. It was the start of the blueprint-maven-plugin as this was the only way to do migration without a big bang. So if you
> have to do this then the annotation based approach + the plugin above can help a lot. If someone wants to try this I can help with some good advices. If there is some interest I can also blog about
> how to do such a transition in practice.
>
> A migration to DS will pretty much be a big bang as it is too different from spring to do a smooth transition. I think it is possible to do a full business application in DS but the migration step is bigger.
>
> Christian
>
> On 21.03.2016 02:24, Tim Jones wrote:
>> Andreas you are crossing or about to cross a bridge we are crossing at the
>> moment. We also have a SpringDM based application. It is 3+ years in
>> production and so a change as large as moving away from SpringDM is very
>> disruptive. For the most part we considered only Aries Blueprint vs DS.
>> However as you can see from this post there are other alternatives, some
>> fairly recent such as support for Spring namespaces in Aries Blueprint.
>>
>> For us the most significant points to consider were
>>
>> 1) Will there still be good support in 5-10 years (having been burnt once we
>> don't want face the same issue again)
>>
>> 2) Where is the general OSGi community heading? Blueprint/DS/other. The
>> first sentence of Tim Ward's post is something we thought significant.
>> Something that has concerned me over the last couple of years is sometimes
>> an alternative is suggested by needs some jiggery pokery to make it work, it
>> doesn't have wide support, little documentation, often has bugs which led to
>> a churn of releases. While it may be a cool, clever solution we aren't going
>> to bet our production system on cool and clever only.
>>
>> 3) We are by and large glue coders and don't have the ability nor want to
>> spend the time/resource building our own custom solutions, this is where I
>> think Spring has suited us well until now. We tried to identify what
>> offerings were available for the bits we needed e.g. JPA, JDBC,
>> transactional control, Camel JMS, CXF. It is an opinion only, but from what
>> I could see Blueprint offered the broadest support (see Christian's
>> ecosystems-compared
>> http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider).
>>
>> The big one for us was lack of JPA/JDBC/transactional control for DS, while
>> there were some solutions we wanted something with a 'spec behind it'. This
>> is currently been worked on at the moment
>> (https://github.com/apache/aries/tree/trunk/tx-control) and I think it is a
>> significant piece of work that will make DS a much more attractive
>> proposition in the enterprise/applications space. Admittedly there is a risk
>> in being new adopter however we think the risk is worth it in this case.
>> Camel has a recent DS offering camel-scr (although I think there are some
>> issues with it). Hopefully in time more libraries will offer DS support out
>> of the box.
>>
>> 4) We are not yet sure we will be able to fully realise the pros of the
>> service dynamics that DS offers vs Blueprint as although one of our goals is
>> to be able to 'hot swap' bundles into a running system this may be harder to
>> achieve than we had hoped. We currently do some limited hot swapping with
>> our SpringDM system.
>>
>> 5) Perhaps counter intuitively of less importance to us was the actual ease
>> of transition, Blueprint would almost certainly be easier to migrate to from
>> SpringDM but we think that this is a one off cost that will be outweighed in
>> the long term.
>>
>> Tim
>>
>>
>>
>>
>>
>> --
>> View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045892.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: Blueprint or DS or what to use?
Posted by Christian Schneider <ch...@die-schneider.net>.
Indeed it is difficult to predict where the OSGi community will go in
the future.
For DS the situation is hopefully a little better today than at the time
I did the comparison.
- JPA can be solved today by using the Aries JPA and JPATemplate but it
is not standardized. The upcoming spec hopefully will improve this.
- Services and Remoting can be solved by Remote Service Admin. With ECF
and Aries rsa (CXF-DOSGi) there are now two stacks available on karaf
that can help with this.
Still it can be a little rough if you want to use some special CXF
features. We will have to prove using some good examples / pocs that
Remote Services can fully replace the blueprint CXF namespaces.
Btw. I have some plans for Aries RSA to support application wide
policies. The idea is to define some common aspects of your services
centrally and apply them to all exported OSGi services. So for example
you could define in one central point that all your services with JAXRS
annotations should be auto exported and have single sign on
authentication using STS, SSL encryption and logging.
The migration though is still a big issue.
Some time ago I did the migration of a medium sized production system
from servlet container + spring to karaf + blueprint. The big problem
there was that we had to do the transition
while the main team was going full steam and doing releases. It was the
start of the blueprint-maven-plugin as this was the only way to do
migration without a big bang. So if you
have to do this then the annotation based approach + the plugin above
can help a lot. If someone wants to try this I can help with some good
advices. If there is some interest I can also blog about
how to do such a transition in practice.
A migration to DS will pretty much be a big bang as it is too different
from spring to do a smooth transition. I think it is possible to do a
full business application in DS but the migration step is bigger.
Christian
On 21.03.2016 02:24, Tim Jones wrote:
> Andreas you are crossing or about to cross a bridge we are crossing at the
> moment. We also have a SpringDM based application. It is 3+ years in
> production and so a change as large as moving away from SpringDM is very
> disruptive. For the most part we considered only Aries Blueprint vs DS.
> However as you can see from this post there are other alternatives, some
> fairly recent such as support for Spring namespaces in Aries Blueprint.
>
> For us the most significant points to consider were
>
> 1) Will there still be good support in 5-10 years (having been burnt once we
> don't want face the same issue again)
>
> 2) Where is the general OSGi community heading? Blueprint/DS/other. The
> first sentence of Tim Ward's post is something we thought significant.
> Something that has concerned me over the last couple of years is sometimes
> an alternative is suggested by needs some jiggery pokery to make it work, it
> doesn't have wide support, little documentation, often has bugs which led to
> a churn of releases. While it may be a cool, clever solution we aren't going
> to bet our production system on cool and clever only.
>
> 3) We are by and large glue coders and don't have the ability nor want to
> spend the time/resource building our own custom solutions, this is where I
> think Spring has suited us well until now. We tried to identify what
> offerings were available for the bits we needed e.g. JPA, JDBC,
> transactional control, Camel JMS, CXF. It is an opinion only, but from what
> I could see Blueprint offered the broadest support (see Christian's
> ecosystems-compared
> http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider).
>
> The big one for us was lack of JPA/JDBC/transactional control for DS, while
> there were some solutions we wanted something with a 'spec behind it'. This
> is currently been worked on at the moment
> (https://github.com/apache/aries/tree/trunk/tx-control) and I think it is a
> significant piece of work that will make DS a much more attractive
> proposition in the enterprise/applications space. Admittedly there is a risk
> in being new adopter however we think the risk is worth it in this case.
> Camel has a recent DS offering camel-scr (although I think there are some
> issues with it). Hopefully in time more libraries will offer DS support out
> of the box.
>
> 4) We are not yet sure we will be able to fully realise the pros of the
> service dynamics that DS offers vs Blueprint as although one of our goals is
> to be able to 'hot swap' bundles into a running system this may be harder to
> achieve than we had hoped. We currently do some limited hot swapping with
> our SpringDM system.
>
> 5) Perhaps counter intuitively of less importance to us was the actual ease
> of transition, Blueprint would almost certainly be easier to migrate to from
> SpringDM but we think that this is a one off cost that will be outweighed in
> the long term.
>
> Tim
>
>
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045892.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Blueprint or DS or what to use?
Posted by Tim Jones <ti...@mccarthy.co.nz>.
Andreas you are crossing or about to cross a bridge we are crossing at the
moment. We also have a SpringDM based application. It is 3+ years in
production and so a change as large as moving away from SpringDM is very
disruptive. For the most part we considered only Aries Blueprint vs DS.
However as you can see from this post there are other alternatives, some
fairly recent such as support for Spring namespaces in Aries Blueprint.
For us the most significant points to consider were
1) Will there still be good support in 5-10 years (having been burnt once we
don't want face the same issue again)
2) Where is the general OSGi community heading? Blueprint/DS/other. The
first sentence of Tim Ward's post is something we thought significant.
Something that has concerned me over the last couple of years is sometimes
an alternative is suggested by needs some jiggery pokery to make it work, it
doesn't have wide support, little documentation, often has bugs which led to
a churn of releases. While it may be a cool, clever solution we aren't going
to bet our production system on cool and clever only.
3) We are by and large glue coders and don't have the ability nor want to
spend the time/resource building our own custom solutions, this is where I
think Spring has suited us well until now. We tried to identify what
offerings were available for the bits we needed e.g. JPA, JDBC,
transactional control, Camel JMS, CXF. It is an opinion only, but from what
I could see Blueprint offered the broadest support (see Christian's
ecosystems-compared
http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider).
The big one for us was lack of JPA/JDBC/transactional control for DS, while
there were some solutions we wanted something with a 'spec behind it'. This
is currently been worked on at the moment
(https://github.com/apache/aries/tree/trunk/tx-control) and I think it is a
significant piece of work that will make DS a much more attractive
proposition in the enterprise/applications space. Admittedly there is a risk
in being new adopter however we think the risk is worth it in this case.
Camel has a recent DS offering camel-scr (although I think there are some
issues with it). Hopefully in time more libraries will offer DS support out
of the box.
4) We are not yet sure we will be able to fully realise the pros of the
service dynamics that DS offers vs Blueprint as although one of our goals is
to be able to 'hot swap' bundles into a running system this may be harder to
achieve than we had hoped. We currently do some limited hot swapping with
our SpringDM system.
5) Perhaps counter intuitively of less importance to us was the actual ease
of transition, Blueprint would almost certainly be easier to migrate to from
SpringDM but we think that this is a one off cost that will be outweighed in
the long term.
Tim
--
View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045892.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Blueprint or DS or what to use?
Posted by Timothy Ward <ti...@paremus.com>.
Hi,
From an OSGi standards perspective it’s worth pointing out that the Blueprint specification has not been touched since it was first released in OSGi 4.2. There are a few proposed extension RFCs for Blueprint, but none have seen much activity in five years or more.
Declarative Services, however, has been actively extended with new features over the last few specification releases. Annotation-based metadata, type-safe configuration, PrototypeServiceFactory support, field injection support, and dynamic service wiring control using Configuration Admin are all cool DS features that seem unlikely to ever make it into a Blueprint standard.
Karaf and Apache Aries have done a lot of work to enhance the Blueprint Container with namespaces and interceptors, however all of these additions are implementation specific and tie you in to that particular stack. This is not a problem for some applications, and is a problem for others.
In summary, moving your application from Spring DM to Blueprint will almost certainly be faster to achieve because Blueprint was heavily based on Spring DM. I, however, would use this opportunity to move to DS because the standard is actively being maintained and extended. As further food for thought, the OSGi enRoute project (http://enroute.osgi.org <http://enroute.osgi.org/>) is entirely DS based, and doesn’t offer Blueprint in its platform at all.
I wish you all the best with your decision.
Regards,
Tim
> On 18 Mar 2016, at 10:30, Christian Schneider <ch...@die-schneider.net> wrote:
>
> I have a comparison in my DS tutorial.
>
> http://www.liquid-reality.de/display/liquid/2015/06/30/Apache+Karaf+Tutorial+part+10+-+Declarative+services
>
> The main two things missing in DS are the namespaces and the interceptors. In karaf internally we would not need those.
> In a typical user application blueprint is probably still better.
>
> Christian
>
> On 18.03.2016 11:24, akuhtz wrote:
>> Hello,
>>
>> I've an application running with spring-dm and because spring-dm is no
>> longer developed I'm looking for a replacement.
>>
>> Now I'm confused because there was a shift in karaf (core) from blueprint to
>> DS and today I saw a post on the dev list, saying that DS does not support
>> as much as blueprint does.
>> As an end-user I would like to know what the proposed way to go is: DS or
>> blueprint, both or what else?
>>
>>
>>
>> --
>> View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: Blueprint or DS or what to use?
Posted by Christian Schneider <ch...@die-schneider.net>.
I have a comparison in my DS tutorial.
http://www.liquid-reality.de/display/liquid/2015/06/30/Apache+Karaf+Tutorial+part+10+-+Declarative+services
The main two things missing in DS are the namespaces and the
interceptors. In karaf internally we would not need those.
In a typical user application blueprint is probably still better.
Christian
On 18.03.2016 11:24, akuhtz wrote:
> Hello,
>
> I've an application running with spring-dm and because spring-dm is no
> longer developed I'm looking for a replacement.
>
> Now I'm confused because there was a shift in karaf (core) from blueprint to
> DS and today I saw a post on the dev list, saying that DS does not support
> as much as blueprint does.
> As an end-user I would like to know what the proposed way to go is: DS or
> blueprint, both or what else?
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Blueprint or DS or what to use?
Posted by Guillaume Nodet <gn...@apache.org>.
No, there aren't any docs at the moment, and it has not been much used yet.
I haven't had any time to write a karaf feature for it yet ...
The blueprint-spring bundle allows you to use the standard spring namespace
along with spring custom namespaces from blueprint applications.
The blueprint-spring-extender bundle will act as the Spring-DM extender and
create a blueprint application for a spring-dm bundle.
Let me know if you hit any problem, I'd be happy to help you.
2016-03-18 18:17 GMT+01:00 Nick Baker <nb...@pentaho.com>:
> Can you point me to any documentation on this? I found a thread on the
> aries-dev but that's about it. When we abandoned Gemini we lost some of the
> functionality and would be interested in trying this out.
>
>
> http://mail-archives.apache.org/mod_mbox/aries-dev/201511.mbox/%3CCAA66TppfYb33D7M234DDEuGxA6dj5Jv24M09VV7u77DbjLOApw@mail.gmail.com%3E
>
> Thanks!
>
> From: Guillaume Nodet <gn...@apache.org>
> Reply-To: "user@karaf.apache.org" <us...@karaf.apache.org>
> Date: Friday, March 18, 2016 at 8:40 AM
> To: user <us...@karaf.apache.org>
> Subject: Re: Blueprint or DS or what to use?
>
> Fwiw, Aries Blueprint now has almost full support for Spring namespaces
> and Spring-DM bundles, you simply need to deploy blueprint, spring and the
> blueprint-spring + blueprint-spring-extender bundles.
>
> 2016-03-18 11:24 GMT+01:00 akuhtz <an...@gmail.com>:
>
>> Hello,
>>
>> I've an application running with spring-dm and because spring-dm is no
>> longer developed I'm looking for a replacement.
>>
>> Now I'm confused because there was a shift in karaf (core) from blueprint
>> to
>> DS and today I saw a post on the dev list, saying that DS does not support
>> as much as blueprint does.
>> As an end-user I would like to know what the proposed way to go is: DS or
>> blueprint, both or what else?
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: Blueprint or DS or what to use?
Posted by Nick Baker <nb...@pentaho.com>.
Can you point me to any documentation on this? I found a thread on the aries-dev but that's about it. When we abandoned Gemini we lost some of the functionality and would be interested in trying this out.
http://mail-archives.apache.org/mod_mbox/aries-dev/201511.mbox/%3CCAA66TppfYb33D7M234DDEuGxA6dj5Jv24M09VV7u77DbjLOApw@mail.gmail.com%3E
Thanks!
From: Guillaume Nodet <gn...@apache.org>>
Reply-To: "user@karaf.apache.org<ma...@karaf.apache.org>" <us...@karaf.apache.org>>
Date: Friday, March 18, 2016 at 8:40 AM
To: user <us...@karaf.apache.org>>
Subject: Re: Blueprint or DS or what to use?
Fwiw, Aries Blueprint now has almost full support for Spring namespaces and Spring-DM bundles, you simply need to deploy blueprint, spring and the blueprint-spring + blueprint-spring-extender bundles.
2016-03-18 11:24 GMT+01:00 akuhtz <an...@gmail.com>>:
Hello,
I've an application running with spring-dm and because spring-dm is no
longer developed I'm looking for a replacement.
Now I'm confused because there was a shift in karaf (core) from blueprint to
DS and today I saw a post on the dev list, saying that DS does not support
as much as blueprint does.
As an end-user I would like to know what the proposed way to go is: DS or
blueprint, both or what else?
--
View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
Sent from the Karaf - User mailing list archive at Nabble.com.
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
Re: Blueprint or DS or what to use?
Posted by Guillaume Nodet <gn...@apache.org>.
Fwiw, Aries Blueprint now has almost full support for Spring namespaces and
Spring-DM bundles, you simply need to deploy blueprint, spring and the
blueprint-spring + blueprint-spring-extender bundles.
2016-03-18 11:24 GMT+01:00 akuhtz <an...@gmail.com>:
> Hello,
>
> I've an application running with spring-dm and because spring-dm is no
> longer developed I'm looking for a replacement.
>
> Now I'm confused because there was a shift in karaf (core) from blueprint
> to
> DS and today I saw a post on the dev list, saying that DS does not support
> as much as blueprint does.
> As an end-user I would like to know what the proposed way to go is: DS or
> blueprint, both or what else?
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: Blueprint or DS or what to use?
Posted by Guillaume Nodet <gn...@apache.org>.
Fwiw, you need to use the following bundles (blueprint-core,
blueprint-spring, blueprint-spring-extender) which are being released:
https://repository.apache.org/content/repositories/orgapachearies-1061
2016-03-18 17:08 GMT+01:00 akuhtz <an...@gmail.com>:
> Hello,
>
> Thank you for all the helpful answers and pointers!
>
> I'll try to go first with the solution proposed by Guillaume and see if I
> get it working.
>
> Regards,
> Andreas
>
> 2016-03-18 14:10 GMT+01:00 CLEMENT Jean-Philippe [via Karaf] <
> ml-node+s922171n4045858h29@n3.nabble.com>:
>
> > We use Blueprint mainly to have a code which makes use of services but
> > without dealing with OSGi or annotations (as far as possible => few
> > wappers). As long with the maven-bundle-plugin it is a kind of magic. I
> > would say Blueprint+Maven+Karaf makes things really easy.
> >
> > I would suggest to make a simple but representative example using CDI,
> DS,
> > and Blueprint. Take time to have a full picture with you editor, plugins
> > and compilation / assembly. See what is means in terms of effort to make,
> > and think about what it would cost to enhance and maintain.
> >
> > JP
> >
> > -----Message d'origine-----
> > De : akuhtz [mailto:[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4045858&i=0>]
> > Envoyé : vendredi 18 mars 2016 11:24
> > À : [hidden email] <http://
> /user/SendEmail.jtp?type=node&node=4045858&i=1>
> > Objet : Blueprint or DS or what to use?
> >
> > Hello,
> >
> > I've an application running with spring-dm and because spring-dm is no
> > longer developed I'm looking for a replacement.
> >
> > Now I'm confused because there was a shift in karaf (core) from blueprint
> > to DS and today I saw a post on the dev list, saying that DS does not
> > support as much as blueprint does.
> > As an end-user I would like to know what the proposed way to go is: DS or
> > blueprint, both or what else?
> >
> >
> >
> > --
> > View this message in context:
> >
> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.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/Blueprint-or-DS-or-what-to-use-tp4045845p4045858.html
> > To unsubscribe from Blueprint or DS or what to use?, click here
> > <
> http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4045845&code=YW5kcmVhcy5rdWh0ekBnbWFpbC5jb218NDA0NTg0NXwtNjQyODAyMjE1
> >
> > .
> > NAML
> > <
> http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045860.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: Blueprint or DS or what to use?
Posted by akuhtz <an...@gmail.com>.
Hello,
Thank you for all the helpful answers and pointers!
I'll try to go first with the solution proposed by Guillaume and see if I
get it working.
Regards,
Andreas
2016-03-18 14:10 GMT+01:00 CLEMENT Jean-Philippe [via Karaf] <
ml-node+s922171n4045858h29@n3.nabble.com>:
> We use Blueprint mainly to have a code which makes use of services but
> without dealing with OSGi or annotations (as far as possible => few
> wappers). As long with the maven-bundle-plugin it is a kind of magic. I
> would say Blueprint+Maven+Karaf makes things really easy.
>
> I would suggest to make a simple but representative example using CDI, DS,
> and Blueprint. Take time to have a full picture with you editor, plugins
> and compilation / assembly. See what is means in terms of effort to make,
> and think about what it would cost to enhance and maintain.
>
> JP
>
> -----Message d'origine-----
> De : akuhtz [mailto:[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4045858&i=0>]
> Envoyé : vendredi 18 mars 2016 11:24
> À : [hidden email] <http:///user/SendEmail.jtp?type=node&node=4045858&i=1>
> Objet : Blueprint or DS or what to use?
>
> Hello,
>
> I've an application running with spring-dm and because spring-dm is no
> longer developed I'm looking for a replacement.
>
> Now I'm confused because there was a shift in karaf (core) from blueprint
> to DS and today I saw a post on the dev list, saying that DS does not
> support as much as blueprint does.
> As an end-user I would like to know what the proposed way to go is: DS or
> blueprint, both or what else?
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.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/Blueprint-or-DS-or-what-to-use-tp4045845p4045858.html
> To unsubscribe from Blueprint or DS or what to use?, click here
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4045845&code=YW5kcmVhcy5rdWh0ekBnbWFpbC5jb218NDA0NTg0NXwtNjQyODAyMjE1>
> .
> NAML
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045860.html
Sent from the Karaf - User mailing list archive at Nabble.com.
RE: Blueprint or DS or what to use?
Posted by CLEMENT Jean-Philippe <je...@fr.thalesgroup.com>.
We use Blueprint mainly to have a code which makes use of services but without dealing with OSGi or annotations (as far as possible => few wappers). As long with the maven-bundle-plugin it is a kind of magic. I would say Blueprint+Maven+Karaf makes things really easy.
I would suggest to make a simple but representative example using CDI, DS, and Blueprint. Take time to have a full picture with you editor, plugins and compilation / assembly. See what is means in terms of effort to make, and think about what it would cost to enhance and maintain.
JP
-----Message d'origine-----
De : akuhtz [mailto:andreas.kuhtz@gmail.com]
Envoyé : vendredi 18 mars 2016 11:24
À : user@karaf.apache.org
Objet : Blueprint or DS or what to use?
Hello,
I've an application running with spring-dm and because spring-dm is no longer developed I'm looking for a replacement.
Now I'm confused because there was a shift in karaf (core) from blueprint to DS and today I saw a post on the dev list, saying that DS does not support as much as blueprint does.
As an end-user I would like to know what the proposed way to go is: DS or blueprint, both or what else?
--
View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Blueprint or DS or what to use?
Posted by Christian Schneider <ch...@die-schneider.net>.
On 18.03.2016 13:07, Charlie Mordant wrote:
> Let introduce an other player: Pax-CDI!
>
> It is fully annotation based and a well known JavaEE standard with
> some additional annotations to deal with OSGi services.
> I really prefer this way for development.
>
> I'm used to deal with these 3 technologies and here are the case where
> I use one or another:
>
> * I'm using blueprint when:
> * * I would do spring xml binding to third parties classes: e.g.
> declaring ciphers or crypto algorthms binding... In this case
> Annotation-based configurations comes with some boilerplate code.
> * * When dealing with JPA/JTA: Aries Jpa and Aries transactions are
> really nice OSGi integration stacks and they're blueprint based.
> * * When I dealing with some init/destroy-methods in a bundle fragment.
>
> * I'm using Declarative service when I have to code some low-level
> modules (all modules where the stack shouldn't need BP or CDI): DS is
> lighter than its concurrent.
>
> * I'm using Pax-CDI everywhere else: its really a pleasure to just add
> @Inject @OsgiService on a bean attribute.
>
You can also mix CDI and blueprint using the blueprint-maven-plugin. It
allows to use the cdi annotations even when you also need to specify
parts of the blueprint by hand.
Of course the annotations are then parsed at build time only and you
only have a subset of CDI but it is better than hand coding xml.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Blueprint or DS or what to use?
Posted by Charlie Mordant <cm...@gmail.com>.
Let introduce an other player: Pax-CDI!
It is fully annotation based and a well known JavaEE standard with some
additional annotations to deal with OSGi services.
I really prefer this way for development.
I'm used to deal with these 3 technologies and here are the case where I
use one or another:
* I'm using blueprint when:
* * I would do spring xml binding to third parties classes: e.g. declaring
ciphers or crypto algorthms binding... In this case Annotation-based
configurations comes with some boilerplate code.
* * When dealing with JPA/JTA: Aries Jpa and Aries transactions are really
nice OSGi integration stacks and they're blueprint based.
* * When I dealing with some init/destroy-methods in a bundle fragment.
* I'm using Declarative service when I have to code some low-level modules
(all modules where the stack shouldn't need BP or CDI): DS is lighter than
its concurrent.
* I'm using Pax-CDI everywhere else: its really a pleasure to just add
@Inject @OsgiService on a bean attribute.
Regards,
Charlie
2016-03-18 12:21 GMT+01:00 ellirael <el...@mail.ru>:
> I personally use Blueprint cause of:
> 1. common spring-like xml style of DI
> 2. prototype scopes
> 3. creating and describing internal skeleton of bundle in one file
> 4. CXF integration
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045852.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
Charlie Mordant
Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent
Re: Blueprint or DS or what to use?
Posted by ellirael <el...@mail.ru>.
I personally use Blueprint cause of:
1. common spring-like xml style of DI
2. prototype scopes
3. creating and describing internal skeleton of bundle in one file
4. CXF integration
--
View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045852.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Blueprint or DS or what to use?
Posted by "Jamie G." <ja...@gmail.com>.
Depends upon your application, and what you want to do.
Each has their benefits, and detractions.
Personally I tend to use Blueprint for small wiring setups (say an AMQ
connection factory, and a Camel Context).
On Fri, Mar 18, 2016 at 7:54 AM, akuhtz <an...@gmail.com> wrote:
> Hello,
>
> I've an application running with spring-dm and because spring-dm is no
> longer developed I'm looking for a replacement.
>
> Now I'm confused because there was a shift in karaf (core) from blueprint to
> DS and today I saw a post on the dev list, saying that DS does not support
> as much as blueprint does.
> As an end-user I would like to know what the proposed way to go is: DS or
> blueprint, both or what else?
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
> Sent from the Karaf - User mailing list archive at Nabble.com.