You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Brad Johnson <br...@mediadriver.com> on 2016/08/21 00:38:05 UTC

Camel SCR and CDI

I've been working a bit with both the Camel SCR and CDI lately.  The CDI is
quite impressive and works very well. SCR I'm not so certain about yet.

What I'm really unsure about is if they are compatible and can be used
together.  I don't suppose there is anything that technically keeps them
from working together but the examples of Camel SCR use the AbstractCamel
runner which requires a list of route builders.

The Camel CDI automatically runs RouteBuilders it finds that are marked as
such so it might end up with two of them making two starts.

Are they not supposed to be used together?

Part of what makes this a real question for me know is the Kura library as
well.  It has an OSGi way of exposing it to the world.

<scr:component name="org.eclipse.kura.example.camel.MyKuraRouter"
activate="activate" deactivate="deactivate" enabled="true" immediate="true">
  <implementation class="org.eclipse.kura.example.camel.MyKuraRouter"/>
</scr:component>

So it's difficult to imagine how all three of those technologies might be
used together or if they should be used together.

Any insights or thoughts or guesses are appreciated.
Brad

Re: Camel SCR and CDI

Posted by Brad Johnson <br...@mediadriver.com>.
From my experience with SCR it is the weaker side of the equation.  The CDI
seems to work just fine.  I'd sort of looked at SCR initially as a way to
manage external services, references and properties while using CDI as the
internal bean and route building mechanism.  But that seems a misfit right
now.  If Guillaume has the OSGiService annotations in then I'll have little
need for SCR.

And I certainly can live without services in the short terms and use Camel
routes with direct-vm calls to take care of the problem.  You've answered
my main concern about CDI spilling outside the classloader and allowing me
to keep my implementation internal and protected especially for versioning
purposes.

Come to think of it I fired up a copy of 6.3.0xxx-157 from a couple of
weeks ago and ran a features install of camel-cdi and this was part of the
package list. So I should have known the pax-cdi was part of it.

[ 294] [Active     ] [            ] [       ] [   80] CDI APIs (1.2.0)
[ 295] [Active     ] [            ] [       ] [   80] OPS4J Pax Swissbox ::
Tracker (1.8.2)
[ 296] [Active     ] [            ] [       ] [   80] OPS4J Pax Swissbox ::
Lifecycle (1.8.2)
[ 297] [Active     ] [            ] [       ] [   80] OPS4J Pax CDI
Extender for Bean Bundles (1.0.0.RC1)
[ 298] [Active     ] [            ] [       ] [   80] OPS4J Pax CDI Bean
Bundle API (1.0.0.RC1)
[ 299] [Active     ] [            ] [       ] [   80] OPS4J Pax CDI Service
Provider Interface (1.0.0.RC1)
[ 300] [Active     ] [            ] [       ] [   80] OPS4J Pax CDI
Portable Extension for OSGi (1.0.0.RC1)
[ 301] [Active     ] [            ] [       ] [   50] camel-core-osgi
(2.17.0.redhat-630157)
[ 302] [Active     ] [            ] [       ] [   50] camel-cdi
(2.17.0.redhat-630157)

On Mon, Aug 22, 2016 at 10:33 AM, Antonin Stefanutti <an...@stefanutti.fr>
wrote:

> Hi Brad,
>
> Camel CDI only works at the level of CDI beans, that is it won’t manage
> RouteBuilder instances that are declared as SCR component.
>
> Then you can imagine having Camel CDI and SCR components collaborating
> through the OSGi registry, using PAX CDI in the mix.
>
> That being said, Camel CDI / SCR integration is an area that still needs
> some work.
>
> Antonin
>
> > On 21 Aug 2016, at 02:38, Brad Johnson <br...@mediadriver.com>
> wrote:
> >
> > I've been working a bit with both the Camel SCR and CDI lately.  The CDI
> is
> > quite impressive and works very well. SCR I'm not so certain about yet.
> >
> > What I'm really unsure about is if they are compatible and can be used
> > together.  I don't suppose there is anything that technically keeps them
> > from working together but the examples of Camel SCR use the AbstractCamel
> > runner which requires a list of route builders.
> >
> > The Camel CDI automatically runs RouteBuilders it finds that are marked
> as
> > such so it might end up with two of them making two starts.
> >
> > Are they not supposed to be used together?
> >
> > Part of what makes this a real question for me know is the Kura library
> as
> > well.  It has an OSGi way of exposing it to the world.
> >
> > <scr:component name="org.eclipse.kura.example.camel.MyKuraRouter"
> > activate="activate" deactivate="deactivate" enabled="true"
> immediate="true">
> >  <implementation class="org.eclipse.kura.example.camel.MyKuraRouter"/>
> > </scr:component>
> >
> > So it's difficult to imagine how all three of those technologies might be
> > used together or if they should be used together.
> >
> > Any insights or thoughts or guesses are appreciated.
> > Brad
>
>

Re: Camel SCR and CDI

Posted by Antonin Stefanutti <an...@stefanutti.fr>.
Hi Brad,

Camel CDI only works at the level of CDI beans, that is it won’t manage RouteBuilder instances that are declared as SCR component.

Then you can imagine having Camel CDI and SCR components collaborating through the OSGi registry, using PAX CDI in the mix.

That being said, Camel CDI / SCR integration is an area that still needs some work.

Antonin

> On 21 Aug 2016, at 02:38, Brad Johnson <br...@mediadriver.com> wrote:
> 
> I've been working a bit with both the Camel SCR and CDI lately.  The CDI is
> quite impressive and works very well. SCR I'm not so certain about yet.
> 
> What I'm really unsure about is if they are compatible and can be used
> together.  I don't suppose there is anything that technically keeps them
> from working together but the examples of Camel SCR use the AbstractCamel
> runner which requires a list of route builders.
> 
> The Camel CDI automatically runs RouteBuilders it finds that are marked as
> such so it might end up with two of them making two starts.
> 
> Are they not supposed to be used together?
> 
> Part of what makes this a real question for me know is the Kura library as
> well.  It has an OSGi way of exposing it to the world.
> 
> <scr:component name="org.eclipse.kura.example.camel.MyKuraRouter"
> activate="activate" deactivate="deactivate" enabled="true" immediate="true">
>  <implementation class="org.eclipse.kura.example.camel.MyKuraRouter"/>
> </scr:component>
> 
> So it's difficult to imagine how all three of those technologies might be
> used together or if they should be used together.
> 
> Any insights or thoughts or guesses are appreciated.
> Brad