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 05:07:42 UTC

Question about OSGi services with Camel 2.17

When I look at the example provided I'm not entirely sure if I'm
understanding how the CDI OSGi service mechanics work.

    @Produces
    @Named("sjms")
    @ApplicationScoped
SjmsComponent sjms()

I gather because it is ApplicationScoped that gets exported via the OSGi
service registry? But it is also a Camel component which may have other in
built mechanisms that might be required. If it isn't ApplicationScoped does
it stay private to the bundle using it?  I'm thinking of properties for
example which might have their own configurations per bundle that one
doesn't want being exported to the world.

If I have an interface like PaypalService and then a concrete
implementation of that called PayPalImpl, would this work to export the
service to the OSGi service registry?

    @Produces
    @Named("paypal")
    @ApplicationScoped
PayPal paypal() {
//Disregarding any special setup...
  return new PayPalImpl();
}

Or would that PayPalImpl have to extend a CamelComponent to get that
behavior?

Right now I'm running and using this only from Eclipse and the CDI unit
test runner which works brilliantly and I don't have to use bueprint for
anything.  But I will want to export services from some bundles while
making sure that the visibility is appropriate.

Brad

Re: Question about OSGi services with Camel 2.17

Posted by Brad Johnson <br...@mediadriver.com>.
Based on your lead I just added the pax-cdi-api and now have access to the
OSGiProvider API.  That might be a good one to add to the camel-cdi
example.  At this point I'm quite happy to just stick with the excellent
job done on the CDI and not bother with SCR or any from DS.  If I recall
right Guillaume said that he'd created proxies a la blueprint for those
annotations and didn't export them as DS does.  That's really not a big
deal to me as I don't have a ton of them and really haven't had any issues
as an end user with the proxies.

<dependency>
<groupId>org.ops4j.pax.cdi</groupId>
<artifactId>pax-cdi-api</artifactId>
<version>1.0.0.RC1</version>
</dependency>

On Mon, Aug 22, 2016 at 11:25 AM, Brad Johnson <brad.johnson@mediadriver.com
> wrote:

> Cool.  Thanks. That's perfect.
>
> Brad
>
> On Mon, Aug 22, 2016 at 10:22 AM, Antonin Stefanutti <
> antonin@stefanutti.fr> wrote:
>
>> Hi Brad,
>>
>> > On 21 Aug 2016, at 07:07, Brad Johnson <br...@mediadriver.com>
>> wrote:
>> >
>> > When I look at the example provided I'm not entirely sure if I'm
>> > understanding how the CDI OSGi service mechanics work.
>> >
>> >    @Produces
>> >    @Named("sjms")
>> >    @ApplicationScoped
>> > SjmsComponent sjms()
>> >
>> > I gather because it is ApplicationScoped that gets exported via the OSGi
>> > service registry? But it is also a Camel component which may have other
>> in
>> > built mechanisms that might be required. If it isn't ApplicationScoped
>> does
>> > it stay private to the bundle using it?  I'm thinking of properties for
>> > example which might have their own configurations per bundle that one
>> > doesn't want being exported to the world.
>>
>> The @ApplicationScoped scope does not mean the bean gets exported into
>> the OSGi service registry. In that case, it’s the Camel registry that is
>> specifically wrapped in OSGi environments so that Camel components get
>> exported to and can be looked up from the OSGi service registry.
>>
>> So the CDI beans are within the scope of the bundle, as there is one CDI
>> container started per bundle which requires the CDI capability.
>>
>> > If I have an interface like PaypalService and then a concrete
>> > implementation of that called PayPalImpl, would this work to export the
>> > service to the OSGi service registry?
>> >
>> >    @Produces
>> >    @Named("paypal")
>> >    @ApplicationScoped
>> > PayPal paypal() {
>> > //Disregarding any special setup...
>> >  return new PayPalImpl();
>> > }
>>
>> It won’t be exported in the OSGi service registry.
>>
>> > Or would that PayPalImpl have to extend a CamelComponent to get that
>> > behaviour?
>>
>> To get the PayPal service exported in the OSGi service registry, you
>> could rely on the @OsgiServiceProvider qualifier that’s provided by the PAX
>> CDI API (https://github.com/ops4j/org.ops4j.pax.cdi/tree/master/pax-
>> cdi-api/src/main/java/org/ops4j/pax/cdi/api).
>>
>> Antonin
>>
>>
>

Re: Question about OSGi services with Camel 2.17

Posted by Brad Johnson <br...@mediadriver.com>.
Cool.  Thanks. That's perfect.

Brad

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

> Hi Brad,
>
> > On 21 Aug 2016, at 07:07, Brad Johnson <br...@mediadriver.com>
> wrote:
> >
> > When I look at the example provided I'm not entirely sure if I'm
> > understanding how the CDI OSGi service mechanics work.
> >
> >    @Produces
> >    @Named("sjms")
> >    @ApplicationScoped
> > SjmsComponent sjms()
> >
> > I gather because it is ApplicationScoped that gets exported via the OSGi
> > service registry? But it is also a Camel component which may have other
> in
> > built mechanisms that might be required. If it isn't ApplicationScoped
> does
> > it stay private to the bundle using it?  I'm thinking of properties for
> > example which might have their own configurations per bundle that one
> > doesn't want being exported to the world.
>
> The @ApplicationScoped scope does not mean the bean gets exported into the
> OSGi service registry. In that case, it’s the Camel registry that is
> specifically wrapped in OSGi environments so that Camel components get
> exported to and can be looked up from the OSGi service registry.
>
> So the CDI beans are within the scope of the bundle, as there is one CDI
> container started per bundle which requires the CDI capability.
>
> > If I have an interface like PaypalService and then a concrete
> > implementation of that called PayPalImpl, would this work to export the
> > service to the OSGi service registry?
> >
> >    @Produces
> >    @Named("paypal")
> >    @ApplicationScoped
> > PayPal paypal() {
> > //Disregarding any special setup...
> >  return new PayPalImpl();
> > }
>
> It won’t be exported in the OSGi service registry.
>
> > Or would that PayPalImpl have to extend a CamelComponent to get that
> > behaviour?
>
> To get the PayPal service exported in the OSGi service registry, you could
> rely on the @OsgiServiceProvider qualifier that’s provided by the PAX CDI
> API (https://github.com/ops4j/org.ops4j.pax.cdi/tree/master/pax-
> cdi-api/src/main/java/org/ops4j/pax/cdi/api).
>
> Antonin
>
>

Re: Question about OSGi services with Camel 2.17

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

> On 21 Aug 2016, at 07:07, Brad Johnson <br...@mediadriver.com> wrote:
> 
> When I look at the example provided I'm not entirely sure if I'm
> understanding how the CDI OSGi service mechanics work.
> 
>    @Produces
>    @Named("sjms")
>    @ApplicationScoped
> SjmsComponent sjms()
> 
> I gather because it is ApplicationScoped that gets exported via the OSGi
> service registry? But it is also a Camel component which may have other in
> built mechanisms that might be required. If it isn't ApplicationScoped does
> it stay private to the bundle using it?  I'm thinking of properties for
> example which might have their own configurations per bundle that one
> doesn't want being exported to the world.

The @ApplicationScoped scope does not mean the bean gets exported into the OSGi service registry. In that case, it’s the Camel registry that is specifically wrapped in OSGi environments so that Camel components get exported to and can be looked up from the OSGi service registry.

So the CDI beans are within the scope of the bundle, as there is one CDI container started per bundle which requires the CDI capability.
 
> If I have an interface like PaypalService and then a concrete
> implementation of that called PayPalImpl, would this work to export the
> service to the OSGi service registry?
> 
>    @Produces
>    @Named("paypal")
>    @ApplicationScoped
> PayPal paypal() {
> //Disregarding any special setup...
>  return new PayPalImpl();
> }

It won’t be exported in the OSGi service registry.

> Or would that PayPalImpl have to extend a CamelComponent to get that
> behaviour?

To get the PayPal service exported in the OSGi service registry, you could rely on the @OsgiServiceProvider qualifier that’s provided by the PAX CDI API (https://github.com/ops4j/org.ops4j.pax.cdi/tree/master/pax-cdi-api/src/main/java/org/ops4j/pax/cdi/api).

Antonin