DS vs Blueprint

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

DS vs Blueprint

Brad Johnson
While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.

But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn't have to worry about start up order.

That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.

What are the views on this?

Brad
Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Johan Edstrom-2
I’ve never seen DS used in the wild other than in places where say
central infrastructure IT provides container services and frameworks.

Still have to see a lot of CDI use and with PaaS offerings and Spring
revamps and a lot of push BP is from what I gather the only viable
alternative.

Just my 0.02c.

Since most developers out there just see it as a tool or necessary evil
in a corporate setting, they don’t really grok services, registrations, proxies,
NamespaceHandlers, SPI providers and so on anyways.

I think it is a very philosophical debate.

/je

> On Aug 27, 2016, at 10:45 AM, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn't have to worry about start up order.
>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad

Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Brad Johnson
Agreed that it is philosophical and can be contentious.  I just started using CDI via pax-cdi and Camel because Camel 2.17 has better support. Also I think the pax-cdi that Guillame and I think JB Onofre created are relatively new. So I've just started using and have a project using it without any Blueprint XML which I've been using for the past number of years.  That required a switch to using the Java DSL for the routebuilder but I didn't find that too painful.  

Brad

On Sat, Aug 27, 2016 at 12:22 PM, Johan Edstrom <[hidden email]> wrote:
I’ve never seen DS used in the wild other than in places where say
central infrastructure IT provides container services and frameworks.

Still have to see a lot of CDI use and with PaaS offerings and Spring
revamps and a lot of push BP is from what I gather the only viable
alternative.

Just my 0.02c.

Since most developers out there just see it as a tool or necessary evil
in a corporate setting, they don’t really grok services, registrations, proxies,
NamespaceHandlers, SPI providers and so on anyways.

I think it is a very philosophical debate.

/je

> On Aug 27, 2016, at 10:45 AM, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn't have to worry about start up order.
>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad


Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Johan Edstrom-2
I actually personally passionately hate not using RouteBuilders so 
for me BP really is about inversion of control and I prefer argument
to properties so I can easily test the same code, not to mention 
I never have to dig for a NPE bean wiring in large systems.


/je

On Aug 27, 2016, at 11:44 AM, Brad Johnson <[hidden email]> wrote:

Agreed that it is philosophical and can be contentious.  I just started using CDI via pax-cdi and Camel because Camel 2.17 has better support. Also I think the pax-cdi that Guillame and I think JB Onofre created are relatively new. So I've just started using and have a project using it without any Blueprint XML which I've been using for the past number of years.  That required a switch to using the Java DSL for the routebuilder but I didn't find that too painful.  

Brad

On Sat, Aug 27, 2016 at 12:22 PM, Johan Edstrom <[hidden email]> wrote:
I’ve never seen DS used in the wild other than in places where say
central infrastructure IT provides container services and frameworks.

Still have to see a lot of CDI use and with PaaS offerings and Spring
revamps and a lot of push BP is from what I gather the only viable
alternative.

Just my 0.02c.

Since most developers out there just see it as a tool or necessary evil
in a corporate setting, they don’t really grok services, registrations, proxies,
NamespaceHandlers, SPI providers and so on anyways.

I think it is a very philosophical debate.

/je

> On Aug 27, 2016, at 10:45 AM, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn't have to worry about start up order.
>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad



Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Matt Sicker
If the Blueprint support in Camel were less Blueprint-biased and more generic to OSGi services, then I feel it would integrate much better with DS. I've been using DS for services more often lately because wiring <bean/>s in an XML file is so blasé, but I still need to use BP to load my Camel routes, and that generally requires making <reference/>s to all my DS services I would need even though they're all obtainable by the name property via service lookup (Camel won't recognise those named services as bean references unless I import them into the BlueprintContainer used by the CamelContext). Unfortunately, it might not be possible for Camel 2.x to fully support the dynamism of DS, but perhaps 3.x could have a more dynamic Registry API that allows for more proper OSGi integration. You can already start, stop, add, and remove routes and components at runtime, but as you've found, this service damping technique is still required due to certain assumptions the Camel API makes about runtime availability of the things your routes reference.

On 27 August 2016 at 13:17, Johan Edstrom <[hidden email]> wrote:
I actually personally passionately hate not using RouteBuilders so 
for me BP really is about inversion of control and I prefer argument
to properties so I can easily test the same code, not to mention 
I never have to dig for a NPE bean wiring in large systems.


/je

On Aug 27, 2016, at 11:44 AM, Brad Johnson <[hidden email]> wrote:

Agreed that it is philosophical and can be contentious.  I just started using CDI via pax-cdi and Camel because Camel 2.17 has better support. Also I think the pax-cdi that Guillame and I think JB Onofre created are relatively new. So I've just started using and have a project using it without any Blueprint XML which I've been using for the past number of years.  That required a switch to using the Java DSL for the routebuilder but I didn't find that too painful.  

Brad

On Sat, Aug 27, 2016 at 12:22 PM, Johan Edstrom <[hidden email]> wrote:
I’ve never seen DS used in the wild other than in places where say
central infrastructure IT provides container services and frameworks.

Still have to see a lot of CDI use and with PaaS offerings and Spring
revamps and a lot of push BP is from what I gather the only viable
alternative.

Just my 0.02c.

Since most developers out there just see it as a tool or necessary evil
in a corporate setting, they don’t really grok services, registrations, proxies,
NamespaceHandlers, SPI providers and so on anyways.

I think it is a very philosophical debate.

/je

> On Aug 27, 2016, at 10:45 AM, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn't have to worry about start up order.
>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad






--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Matt Sicker
Also, if I could go without seeing a bundle in a GracePeriod state ever again, that would be great. I love lazy evaluation in programming languages, and since DS provides a neat way to lazily load components, it would be great for Camel to support lazy loading of everything as well. This GracePeriod Blueprint hack is rather annoying in practice.

On 27 August 2016 at 13:25, Matt Sicker <[hidden email]> wrote:
If the Blueprint support in Camel were less Blueprint-biased and more generic to OSGi services, then I feel it would integrate much better with DS. I've been using DS for services more often lately because wiring <bean/>s in an XML file is so blasé, but I still need to use BP to load my Camel routes, and that generally requires making <reference/>s to all my DS services I would need even though they're all obtainable by the name property via service lookup (Camel won't recognise those named services as bean references unless I import them into the BlueprintContainer used by the CamelContext). Unfortunately, it might not be possible for Camel 2.x to fully support the dynamism of DS, but perhaps 3.x could have a more dynamic Registry API that allows for more proper OSGi integration. You can already start, stop, add, and remove routes and components at runtime, but as you've found, this service damping technique is still required due to certain assumptions the Camel API makes about runtime availability of the things your routes reference.

On 27 August 2016 at 13:17, Johan Edstrom <[hidden email]> wrote:
I actually personally passionately hate not using RouteBuilders so 
for me BP really is about inversion of control and I prefer argument
to properties so I can easily test the same code, not to mention 
I never have to dig for a NPE bean wiring in large systems.


/je

On Aug 27, 2016, at 11:44 AM, Brad Johnson <[hidden email]> wrote:

Agreed that it is philosophical and can be contentious.  I just started using CDI via pax-cdi and Camel because Camel 2.17 has better support. Also I think the pax-cdi that Guillame and I think JB Onofre created are relatively new. So I've just started using and have a project using it without any Blueprint XML which I've been using for the past number of years.  That required a switch to using the Java DSL for the routebuilder but I didn't find that too painful.  

Brad

On Sat, Aug 27, 2016 at 12:22 PM, Johan Edstrom <[hidden email]> wrote:
I’ve never seen DS used in the wild other than in places where say
central infrastructure IT provides container services and frameworks.

Still have to see a lot of CDI use and with PaaS offerings and Spring
revamps and a lot of push BP is from what I gather the only viable
alternative.

Just my 0.02c.

Since most developers out there just see it as a tool or necessary evil
in a corporate setting, they don’t really grok services, registrations, proxies,
NamespaceHandlers, SPI providers and so on anyways.

I think it is a very philosophical debate.

/je

> On Aug 27, 2016, at 10:45 AM, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn't have to worry about start up order.
>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad






--
Matt Sicker <[hidden email]>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Brad Johnson
In reply to this post by Johan Edstrom-2
I assume you mean  blueprint XML routebuilders and not Java DSL routebuilders?  I've used the XML approach for a long time. CamelBlueprintTestSupport has gotten much better but it still has limitations on multiple contexts and I find I'm commonly debugging the tests as much as making the code run right.  It is also a bit slow and will hang on occasions.

The only issue I've noticed with CDI and the OSGi annotations is that the CamelRunner for CDI uses Weld while the pax-cdi doesn't.  That might be an issue.  CamelSCR still feels half baked.

But I don't have hard and fast opinions about it and am interested in different perspectives.

On Sat, Aug 27, 2016 at 1:17 PM, Johan Edstrom <[hidden email]> wrote:
I actually personally passionately hate not using RouteBuilders so 
for me BP really is about inversion of control and I prefer argument
to properties so I can easily test the same code, not to mention 
I never have to dig for a NPE bean wiring in large systems.


/je

On Aug 27, 2016, at 11:44 AM, Brad Johnson <[hidden email]> wrote:

Agreed that it is philosophical and can be contentious.  I just started using CDI via pax-cdi and Camel because Camel 2.17 has better support. Also I think the pax-cdi that Guillame and I think JB Onofre created are relatively new. So I've just started using and have a project using it without any Blueprint XML which I've been using for the past number of years.  That required a switch to using the Java DSL for the routebuilder but I didn't find that too painful.  

Brad

On Sat, Aug 27, 2016 at 12:22 PM, Johan Edstrom <[hidden email]> wrote:
I’ve never seen DS used in the wild other than in places where say
central infrastructure IT provides container services and frameworks.

Still have to see a lot of CDI use and with PaaS offerings and Spring
revamps and a lot of push BP is from what I gather the only viable
alternative.

Just my 0.02c.

Since most developers out there just see it as a tool or necessary evil
in a corporate setting, they don’t really grok services, registrations, proxies,
NamespaceHandlers, SPI providers and so on anyways.

I think it is a very philosophical debate.

/je

> On Aug 27, 2016, at 10:45 AM, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn't have to worry about start up order.
>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad




Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Matt Sicker
I've been using the Java DSL route builders, and you still need to use Blueprint just to load them via <contextScan/> in the <camelContext/> element.

On 27 August 2016 at 13:44, Brad Johnson <[hidden email]> wrote:
I assume you mean  blueprint XML routebuilders and not Java DSL routebuilders?  I've used the XML approach for a long time. CamelBlueprintTestSupport has gotten much better but it still has limitations on multiple contexts and I find I'm commonly debugging the tests as much as making the code run right.  It is also a bit slow and will hang on occasions.

The only issue I've noticed with CDI and the OSGi annotations is that the CamelRunner for CDI uses Weld while the pax-cdi doesn't.  That might be an issue.  CamelSCR still feels half baked.

But I don't have hard and fast opinions about it and am interested in different perspectives.

On Sat, Aug 27, 2016 at 1:17 PM, Johan Edstrom <[hidden email]> wrote:
I actually personally passionately hate not using RouteBuilders so 
for me BP really is about inversion of control and I prefer argument
to properties so I can easily test the same code, not to mention 
I never have to dig for a NPE bean wiring in large systems.


/je

On Aug 27, 2016, at 11:44 AM, Brad Johnson <[hidden email]> wrote:

Agreed that it is philosophical and can be contentious.  I just started using CDI via pax-cdi and Camel because Camel 2.17 has better support. Also I think the pax-cdi that Guillame and I think JB Onofre created are relatively new. So I've just started using and have a project using it without any Blueprint XML which I've been using for the past number of years.  That required a switch to using the Java DSL for the routebuilder but I didn't find that too painful.  

Brad

On Sat, Aug 27, 2016 at 12:22 PM, Johan Edstrom <[hidden email]> wrote:
I’ve never seen DS used in the wild other than in places where say
central infrastructure IT provides container services and frameworks.

Still have to see a lot of CDI use and with PaaS offerings and Spring
revamps and a lot of push BP is from what I gather the only viable
alternative.

Just my 0.02c.

Since most developers out there just see it as a tool or necessary evil
in a corporate setting, they don’t really grok services, registrations, proxies,
NamespaceHandlers, SPI providers and so on anyways.

I think it is a very philosophical debate.

/je

> On Aug 27, 2016, at 10:45 AM, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn't have to worry about start up order.
>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad







--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Brad Johnson
The Camel 2.17 CDI implementation will automatically pick up the RouteBuilders. I was kicking the tires on it and was very pleased. The RouteBuilders in turn pick up their dependencies from either in bundle annotated beans and providers or from external OSGi services.  Pretty slick.

Matt, do you use the XML version of DS or annotations?

Brad

On Sat, Aug 27, 2016 at 1:49 PM, Matt Sicker <[hidden email]> wrote:
I've been using the Java DSL route builders, and you still need to use Blueprint just to load them via <contextScan/> in the <camelContext/> element.

On 27 August 2016 at 13:44, Brad Johnson <[hidden email]> wrote:
I assume you mean  blueprint XML routebuilders and not Java DSL routebuilders?  I've used the XML approach for a long time. CamelBlueprintTestSupport has gotten much better but it still has limitations on multiple contexts and I find I'm commonly debugging the tests as much as making the code run right.  It is also a bit slow and will hang on occasions.

The only issue I've noticed with CDI and the OSGi annotations is that the CamelRunner for CDI uses Weld while the pax-cdi doesn't.  That might be an issue.  CamelSCR still feels half baked.

But I don't have hard and fast opinions about it and am interested in different perspectives.

On Sat, Aug 27, 2016 at 1:17 PM, Johan Edstrom <[hidden email]> wrote:
I actually personally passionately hate not using RouteBuilders so 
for me BP really is about inversion of control and I prefer argument
to properties so I can easily test the same code, not to mention 
I never have to dig for a NPE bean wiring in large systems.


/je

On Aug 27, 2016, at 11:44 AM, Brad Johnson <[hidden email]> wrote:

Agreed that it is philosophical and can be contentious.  I just started using CDI via pax-cdi and Camel because Camel 2.17 has better support. Also I think the pax-cdi that Guillame and I think JB Onofre created are relatively new. So I've just started using and have a project using it without any Blueprint XML which I've been using for the past number of years.  That required a switch to using the Java DSL for the routebuilder but I didn't find that too painful.  

Brad

On Sat, Aug 27, 2016 at 12:22 PM, Johan Edstrom <[hidden email]> wrote:
I’ve never seen DS used in the wild other than in places where say
central infrastructure IT provides container services and frameworks.

Still have to see a lot of CDI use and with PaaS offerings and Spring
revamps and a lot of push BP is from what I gather the only viable
alternative.

Just my 0.02c.

Since most developers out there just see it as a tool or necessary evil
in a corporate setting, they don’t really grok services, registrations, proxies,
NamespaceHandlers, SPI providers and so on anyways.

I think it is a very philosophical debate.

/je

> On Aug 27, 2016, at 10:45 AM, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn't have to worry about start up order.
>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad







--
Matt Sicker <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Matt Sicker
I've been using DS annotations and XML Blueprint. If I can ditch Blueprint for CDI in 2.17, that might be a nice upgrade honestly.

On 27 August 2016 at 14:04, Brad Johnson <[hidden email]> wrote:
The Camel 2.17 CDI implementation will automatically pick up the RouteBuilders. I was kicking the tires on it and was very pleased. The RouteBuilders in turn pick up their dependencies from either in bundle annotated beans and providers or from external OSGi services.  Pretty slick.

Matt, do you use the XML version of DS or annotations?

Brad

On Sat, Aug 27, 2016 at 1:49 PM, Matt Sicker <[hidden email]> wrote:
I've been using the Java DSL route builders, and you still need to use Blueprint just to load them via <contextScan/> in the <camelContext/> element.

On 27 August 2016 at 13:44, Brad Johnson <[hidden email]> wrote:
I assume you mean  blueprint XML routebuilders and not Java DSL routebuilders?  I've used the XML approach for a long time. CamelBlueprintTestSupport has gotten much better but it still has limitations on multiple contexts and I find I'm commonly debugging the tests as much as making the code run right.  It is also a bit slow and will hang on occasions.

The only issue I've noticed with CDI and the OSGi annotations is that the CamelRunner for CDI uses Weld while the pax-cdi doesn't.  That might be an issue.  CamelSCR still feels half baked.

But I don't have hard and fast opinions about it and am interested in different perspectives.

On Sat, Aug 27, 2016 at 1:17 PM, Johan Edstrom <[hidden email]> wrote:
I actually personally passionately hate not using RouteBuilders so 
for me BP really is about inversion of control and I prefer argument
to properties so I can easily test the same code, not to mention 
I never have to dig for a NPE bean wiring in large systems.


/je

On Aug 27, 2016, at 11:44 AM, Brad Johnson <[hidden email]> wrote:

Agreed that it is philosophical and can be contentious.  I just started using CDI via pax-cdi and Camel because Camel 2.17 has better support. Also I think the pax-cdi that Guillame and I think JB Onofre created are relatively new. So I've just started using and have a project using it without any Blueprint XML which I've been using for the past number of years.  That required a switch to using the Java DSL for the routebuilder but I didn't find that too painful.  

Brad

On Sat, Aug 27, 2016 at 12:22 PM, Johan Edstrom <[hidden email]> wrote:
I’ve never seen DS used in the wild other than in places where say
central infrastructure IT provides container services and frameworks.

Still have to see a lot of CDI use and with PaaS offerings and Spring
revamps and a lot of push BP is from what I gather the only viable
alternative.

Just my 0.02c.

Since most developers out there just see it as a tool or necessary evil
in a corporate setting, they don’t really grok services, registrations, proxies,
NamespaceHandlers, SPI providers and so on anyways.

I think it is a very philosophical debate.

/je

> On Aug 27, 2016, at 10:45 AM, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn't have to worry about start up order.
>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad







--
Matt Sicker <[hidden email]>




--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Timothy Ward-2
In reply to this post by Brad Johnson
Hi Brad,

> On 27 Aug 2016, at 17:45, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn’t have to worry about start up order.

Independence of startup ordering is a benefit of using OSGi services in general - it applies to DS, Blueprint, and anything else that uses the OSGi service registry properly. It has little to do with damping.

The service damping from blueprint is actually more harmful than helpful in many cases. As there is never any bean destruction or re-injection there is no way to guarantee that the object reference you hold actually points at anything. When combined with blueprint’s “block for a really long time” behaviour on missing references this can wreak havoc in your system. Optional services are really horrible in this model.

As things stand currently blueprint is most widely used for working with Camel. From what I can tell configuring Camel is horrible, and my understanding is that the main advantage of blueprint is that there is a huge amount of ready-built Camel integration available. If Camel had a nicer, container agnostic configuration mechanism then I would see little reason to choose blueprint over DS.

Regards,

Tim



>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad

Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Matt Sicker
On 2 September 2016 at 11:30, Timothy Ward <[hidden email]> wrote:
As things stand currently blueprint is most widely used for working with Camel. From what I can tell configuring Camel is horrible, and my understanding is that the main advantage of blueprint is that there is a huge amount of ready-built Camel integration available. If Camel had a nicer, container agnostic configuration mechanism then I would see little reason to choose blueprint over DS.

This right here is exactly how I feel. If there was a well supported way of simply using DS instead of Blueprint with Camel, then I'd drop Blueprint in a single sprint and never look back. 
Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Brad Johnson
In reply to this post by Timothy Ward-2
Yes but doesn't the independent start up order of DS require configuration of start up order?

On Fri, Sep 2, 2016 at 11:30 AM, Timothy Ward <[hidden email]> wrote:
Hi Brad,

> On 27 Aug 2016, at 17:45, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn’t have to worry about start up order.

Independence of startup ordering is a benefit of using OSGi services in general - it applies to DS, Blueprint, and anything else that uses the OSGi service registry properly. It has little to do with damping.

The service damping from blueprint is actually more harmful than helpful in many cases. As there is never any bean destruction or re-injection there is no way to guarantee that the object reference you hold actually points at anything. When combined with blueprint’s “block for a really long time” behaviour on missing references this can wreak havoc in your system. Optional services are really horrible in this model.

As things stand currently blueprint is most widely used for working with Camel. From what I can tell configuring Camel is horrible, and my understanding is that the main advantage of blueprint is that there is a huge amount of ready-built Camel integration available. If Camel had a nicer, container agnostic configuration mechanism then I would see little reason to choose blueprint over DS.

Regards,

Tim



>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad


Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Brad Johnson
In reply to this post by Matt Sicker
Matt,

For the past few weeks I've been working with the Camel 2.17 CDI and it's marvelous.  I've been using blueprint for a few years now and I won't be going back to twiddling XML unless I have to (I'm not sure how to set up CXF server without it right now).  But the CDI test runner is fast and a snap to use. The annotation automated wire up and RouteBuilder automatic running is just like you'd think ought to be. 

The pax-cdi implementation actually creates blueprint proxies for annotations like @OSGiServiceProvider and will inject it where you specify the service consumer. The only caveat to the CDI test runner is that it is not OSGi based but uses Weld.  So you have to be careful about what you test but I can live with that.  Truly stunning when one sees a technology that works almost like magic - like you'd dream it should work.

On Fri, Sep 2, 2016 at 12:04 PM, Matt Sicker <[hidden email]> wrote:
On 2 September 2016 at 11:30, Timothy Ward <[hidden email]> wrote:
As things stand currently blueprint is most widely used for working with Camel. From what I can tell configuring Camel is horrible, and my understanding is that the main advantage of blueprint is that there is a huge amount of ready-built Camel integration available. If Camel had a nicer, container agnostic configuration mechanism then I would see little reason to choose blueprint over DS.

This right here is exactly how I feel. If there was a well supported way of simply using DS instead of Blueprint with Camel, then I'd drop Blueprint in a single sprint and never look back. 

Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Brad Johnson
In reply to this post by Brad Johnson

On Fri, Sep 2, 2016 at 12:34 PM, Brad Johnson <[hidden email]> wrote:
Yes but doesn't the independent start up order of DS require configuration of start up order?

On Fri, Sep 2, 2016 at 11:30 AM, Timothy Ward <[hidden email]> wrote:
Hi Brad,

> On 27 Aug 2016, at 17:45, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn’t have to worry about start up order.

Independence of startup ordering is a benefit of using OSGi services in general - it applies to DS, Blueprint, and anything else that uses the OSGi service registry properly. It has little to do with damping.

The service damping from blueprint is actually more harmful than helpful in many cases. As there is never any bean destruction or re-injection there is no way to guarantee that the object reference you hold actually points at anything. When combined with blueprint’s “block for a really long time” behaviour on missing references this can wreak havoc in your system. Optional services are really horrible in this model.

As things stand currently blueprint is most widely used for working with Camel. From what I can tell configuring Camel is horrible, and my understanding is that the main advantage of blueprint is that there is a huge amount of ready-built Camel integration available. If Camel had a nicer, container agnostic configuration mechanism then I would see little reason to choose blueprint over DS.

Regards,

Tim



>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad



Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Matt Sicker
I've never used CDI before, but that's certainly worth looking into. Thanks.

On 2 September 2016 at 12:52, Brad Johnson <[hidden email]> wrote:

On Fri, Sep 2, 2016 at 12:34 PM, Brad Johnson <[hidden email]> wrote:
Yes but doesn't the independent start up order of DS require configuration of start up order?

On Fri, Sep 2, 2016 at 11:30 AM, Timothy Ward <[hidden email]> wrote:
Hi Brad,

> On 27 Aug 2016, at 17:45, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn’t have to worry about start up order.

Independence of startup ordering is a benefit of using OSGi services in general - it applies to DS, Blueprint, and anything else that uses the OSGi service registry properly. It has little to do with damping.

The service damping from blueprint is actually more harmful than helpful in many cases. As there is never any bean destruction or re-injection there is no way to guarantee that the object reference you hold actually points at anything. When combined with blueprint’s “block for a really long time” behaviour on missing references this can wreak havoc in your system. Optional services are really horrible in this model.

As things stand currently blueprint is most widely used for working with Camel. From what I can tell configuring Camel is horrible, and my understanding is that the main advantage of blueprint is that there is a huge amount of ready-built Camel integration available. If Camel had a nicer, container agnostic configuration mechanism then I would see little reason to choose blueprint over DS.

Regards,

Tim



>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad






--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Brad Johnson
I hadn't really either until just recently.  It won't take long to pick it up.  If your bean needs access to a route you just have ProducerTemplate injected.  If your route needs access to a bean you just name the bean with @Named and refer to it in your route with the string "bean:myBeanName".  Same for testing.  If you want to test just the function of some bean you have in for validation you just refer to it in your test with @Inject and the concrete class name.  Bingo.  Almost like magic.  

I'm like and have toiled in the blueprint XML salt mines for a few years and the change makes Camel, already a very good library, now a great library.

On Fri, Sep 2, 2016 at 1:00 PM, Matt Sicker <[hidden email]> wrote:
I've never used CDI before, but that's certainly worth looking into. Thanks.

On 2 September 2016 at 12:52, Brad Johnson <[hidden email]> wrote:

On Fri, Sep 2, 2016 at 12:34 PM, Brad Johnson <[hidden email]> wrote:
Yes but doesn't the independent start up order of DS require configuration of start up order?

On Fri, Sep 2, 2016 at 11:30 AM, Timothy Ward <[hidden email]> wrote:
Hi Brad,

> On 27 Aug 2016, at 17:45, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn’t have to worry about start up order.

Independence of startup ordering is a benefit of using OSGi services in general - it applies to DS, Blueprint, and anything else that uses the OSGi service registry properly. It has little to do with damping.

The service damping from blueprint is actually more harmful than helpful in many cases. As there is never any bean destruction or re-injection there is no way to guarantee that the object reference you hold actually points at anything. When combined with blueprint’s “block for a really long time” behaviour on missing references this can wreak havoc in your system. Optional services are really horrible in this model.

As things stand currently blueprint is most widely used for working with Camel. From what I can tell configuring Camel is horrible, and my understanding is that the main advantage of blueprint is that there is a huge amount of ready-built Camel integration available. If Camel had a nicer, container agnostic configuration mechanism then I would see little reason to choose blueprint over DS.

Regards,

Tim



>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad






--
Matt Sicker <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Timothy Ward-2
In reply to this post by Brad Johnson
As with anything that uses the OSGi Service Registry properly, DS waits for a service to be available before activating a component which uses that service. This means that there is no configuration of startup order, and that there are no points when the graph is incomplete assuming that:

a) All other bundles correctly wait for service dependencies (many do this badly if they try to use the raw OSGi API)
b) All services are registered only when they are usable (again, this is hard when using the low level API)

I know a large number of DS users, none of them need to use start-up ordering to make DS work. The problems that do occur happen when libraries have poorly written OSGi code which does not use a container, and instead use the low level OSGi APIs incorrectly.

Regards,

Tim


On 2 Sep 2016, at 18:34, Brad Johnson <[hidden email]> wrote:

Yes but doesn't the independent start up order of DS require configuration of start up order?

On Fri, Sep 2, 2016 at 11:30 AM, Timothy Ward <[hidden email]> wrote:
Hi Brad,

> On 27 Aug 2016, at 17:45, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn’t have to worry about start up order.

Independence of startup ordering is a benefit of using OSGi services in general - it applies to DS, Blueprint, and anything else that uses the OSGi service registry properly. It has little to do with damping.

The service damping from blueprint is actually more harmful than helpful in many cases. As there is never any bean destruction or re-injection there is no way to guarantee that the object reference you hold actually points at anything. When combined with blueprint’s “block for a really long time” behaviour on missing references this can wreak havoc in your system. Optional services are really horrible in this model.

As things stand currently blueprint is most widely used for working with Camel. From what I can tell configuring Camel is horrible, and my understanding is that the main advantage of blueprint is that there is a huge amount of ready-built Camel integration available. If Camel had a nicer, container agnostic configuration mechanism then I would see little reason to choose blueprint over DS.

Regards,

Tim



>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad



Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Guillaume Nodet-2
In reply to this post by Brad Johnson
I don't really recommend using the @OsgiService / @OsgiServiceProvider of Pax-CDI.
The main reason is that if the bundles are not started in the correct order, the bean validation will simply fail and your CDI app won't be created at all.
I'd really recommend to look at the new annotations of Pax-CDI which haven't been released yet (in 1.0.0-SNAPSHOT).  They are very similar to the DS semantics (and they actually use part of Felix SCR implementation as the core engine).  The lifecycle of the CDI beans is similar to those of DS, so the dependency mechanism is really straightforward from a user point of view.

Cheers,
Guillaume 

2016-09-02 19:46 GMT+02:00 Brad Johnson <[hidden email]>:
Matt,

For the past few weeks I've been working with the Camel 2.17 CDI and it's marvelous.  I've been using blueprint for a few years now and I won't be going back to twiddling XML unless I have to (I'm not sure how to set up CXF server without it right now).  But the CDI test runner is fast and a snap to use. The annotation automated wire up and RouteBuilder automatic running is just like you'd think ought to be. 

The pax-cdi implementation actually creates blueprint proxies for annotations like @OSGiServiceProvider and will inject it where you specify the service consumer. The only caveat to the CDI test runner is that it is not OSGi based but uses Weld.  So you have to be careful about what you test but I can live with that.  Truly stunning when one sees a technology that works almost like magic - like you'd dream it should work.

On Fri, Sep 2, 2016 at 12:04 PM, Matt Sicker <[hidden email]> wrote:
On 2 September 2016 at 11:30, Timothy Ward <[hidden email]> wrote:
As things stand currently blueprint is most widely used for working with Camel. From what I can tell configuring Camel is horrible, and my understanding is that the main advantage of blueprint is that there is a huge amount of ready-built Camel integration available. If Camel had a nicer, container agnostic configuration mechanism then I would see little reason to choose blueprint over DS.

This right here is exactly how I feel. If there was a well supported way of simply using DS instead of Blueprint with Camel, then I'd drop Blueprint in a single sprint and never look back. 




--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration


Reply | Threaded
Open this post in threaded view
|

Re: DS vs Blueprint

Brad Johnson
In reply to this post by Timothy Ward-2
Ah. OK.  That makes it much more palatable.  I had this vision of installing 30 bundles and having to specify start up order.  When you say using low level APIs I suppose you mean things like BundleActivator and it's overriden methods?

I've started working with the SCR in camel and the CDI as well.  To mean it seems like a good combination since I can let the CDI wire up my bundle internals while letting SCR expose that to the world and get properties in.

On Mon, Sep 5, 2016 at 6:14 AM, Timothy Ward <[hidden email]> wrote:
As with anything that uses the OSGi Service Registry properly, DS waits for a service to be available before activating a component which uses that service. This means that there is no configuration of startup order, and that there are no points when the graph is incomplete assuming that:

a) All other bundles correctly wait for service dependencies (many do this badly if they try to use the raw OSGi API)
b) All services are registered only when they are usable (again, this is hard when using the low level API)

I know a large number of DS users, none of them need to use start-up ordering to make DS work. The problems that do occur happen when libraries have poorly written OSGi code which does not use a container, and instead use the low level OSGi APIs incorrectly.

Regards,

Tim



On 2 Sep 2016, at 18:34, Brad Johnson <[hidden email]> wrote:

Yes but doesn't the independent start up order of DS require configuration of start up order?

On Fri, Sep 2, 2016 at 11:30 AM, Timothy Ward <[hidden email]> wrote:
Hi Brad,

> On 27 Aug 2016, at 17:45, Brad Johnson <[hidden email]> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and OSGi services the service damping provided by blueprint seems like a positive benefit in that one doesn’t have to worry about start up order.

Independence of startup ordering is a benefit of using OSGi services in general - it applies to DS, Blueprint, and anything else that uses the OSGi service registry properly. It has little to do with damping.

The service damping from blueprint is actually more harmful than helpful in many cases. As there is never any bean destruction or re-injection there is no way to guarantee that the object reference you hold actually points at anything. When combined with blueprint’s “block for a really long time” behaviour on missing references this can wreak havoc in your system. Optional services are really horrible in this model.

As things stand currently blueprint is most widely used for working with Camel. From what I can tell configuring Camel is horrible, and my understanding is that the main advantage of blueprint is that there is a huge amount of ready-built Camel integration available. If Camel had a nicer, container agnostic configuration mechanism then I would see little reason to choose blueprint over DS.

Regards,

Tim



>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd say the development time is cut in half.  The OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind the scenes but I don't think that's a problem.  What it does do is eliminate the need for all the XML configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad




12