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
