That's what gets a bit confusing about it all. I'm coming from Blueprint
which I've used for a few years now and very much like the automated wiring
provided by CDI and especially the ease of testing. But as I read about DS
and CDI it gets a bit confusing. Camel SCR probably can't work with CDI
since it overrides an AbstractCamelRunner which requires route builder set
up but CDI would likely bootstrap those routes. I don't find not being
able to use SCR a big loss however.
At this point even if I had to give up exporting services into the OSGi
registry I'd probably live with it and simple use routes for integration.
But working with the Camel CDI in 2.17 it is based on Weld, which is fine,
and not on PAX CDI so as you point out the OSGi service annotations aren't
there. Which sort of anticipated the question I had this week end about
whether or not those would be ported. So my dependencies look like this:
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<!-- <camel.version>2.15.1.redhat-621084</camel.version> -->
<camel.version>2.17.3</camel.version>
<cdi.version>1.2</cdi.version>
<src.version>1.8</src.version>
</properties>
<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<version>${cdi.version}</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-cdi</artifactId>
<version>${camel.version}</version>
</dependency>
So then I'm rummaging around trying to figure out how this is going to work
in the OSGi environment (Fuse 6.3 is pregnant and ready to drop an M1 soon
I think). The only difference I can really see there is that the
camel-example-cdi-osgi also contains the basic OSGi pieces as provided and
uses Pax Exam for tests. I think Pax Exam is fine for integration testing
but for basic unit tests it is a bit heavyweight and I'd prefer the Camel
CDI test runner even if I have to mock external services.
<!-- OSGi API -->
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.core</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.compendium</artifactId>
<scope>provided</scope>
</dependency>
When I look at straight DS it gets even more of head scratcher with the
OSGi alliance seeming to push the Bnd Tools.
I had noticed Guillaume's pax.cdi as well but wasn't really sure how that
was going to fit in. Is that something would be added as a
dependency/installed as a feature in addition to camel-cdi?
Thanks for the feedback,
Brad
On Mon, Aug 22, 2016 at 10:08 AM, Antonin Stefanutti <anto...@stefanutti.fr>
wrote:
> Hi Brad,
>
> I’ve been working on Camel CDI in OSGi for a while and have ported my
> original samples to be tested in Karaf, which can be found in [1]. These
> samples exercise the portability of Camel CDI examples on OSGi, thus do not
> leverage the SCR equivalent annotations that PAX CDI provides. So the
> objective here was to prove technically the portability of "plain" Camel
> CDI applications on OSGi. The main outcome has been captured in [2], which
> highlights the difficulty to make the CDI implementations subclass proxying
> mechanism working seamlessly in a class loader constrained environment such
> as OSGi.
>
> Then, from the functional standpoint, Guillaume Nodet has been working
> lately on improving the SCR-like annotation support [3]. Though I haven’t
> found the time yet to test it with Camel CDI in particular.
>
> [1]: https://github.com/astefanutti/camel-cdi/tree/
> master/envs/osgi/src/test/java/org/apache/camel/cdi/osgi
> [2]: https://github.com/ops4j/org.ops4j.pax.cdi/pull/30
> [3]: https://github.com/ops4j/org.ops4j.pax.cdi/tree/master/pax-
> cdi-api/src/main/java/org/ops4j/pax/cdi/api
>
> Antonin
>
> > On 22 Aug 2016, at 16:33, Brad Johnson <brad.john...@mediadriver.com>
> wrote:
> >
> > Has anyone used Camel CDI in an OSGi environment? Does it work well or
> at
> > least OK there?
> >
> > Brad
>
>
