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.john...@mediadriver.com
> wrote:
> Cool. Thanks. That's perfect.
>
> Brad
>
> On Mon, Aug 22, 2016 at 10:22 AM, Antonin Stefanutti <
> anto...@stefanutti.fr> wrote:
>
>> Hi Brad,
>>
>> > On 21 Aug 2016, at 07:07, Brad Johnson <brad.john...@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
>>
>>
>
