camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonin Stefanutti <>
Subject Re: Camel CDI
Date Mon, 22 Aug 2016 15:44:55 GMT
Camel CDI is not based on Weld, it’s only the Camel CDI test facility which relies on it
for the JUnit runner as the simplest way to bootstrap a CDI capable environment. You can quite
easily achieve the same with Arquillian if you need to target other kind of CDI environments,
though Camel CDI test can be adapted if needed.

For the OSGi support, there is already some *optional* OSGi bits in Camel CDI, that adapts
the Camel contexts managed by Camel CDI to be fully capable in OSGi runtimes [1].

Then, the idea is to use the PAX CDI API to have the CDI / OSGi integration. However the SCR
integration is still an open area AFAIK. Obviously, Camel CDI could be improved to integrate
that work at some point, provided that it'll remain optional for other type of users.



> On 22 Aug 2016, at 17:26, Brad Johnson <> wrote:
> 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>
> <>UTF-8</>
> <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 <>
> 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]:
>> master/envs/osgi/src/test/java/org/apache/camel/cdi/osgi
>> [2]:
>> [3]:
>> cdi-api/src/main/java/org/ops4j/pax/cdi/api
>> Antonin
>>> On 22 Aug 2016, at 16:33, Brad Johnson <>
>> wrote:
>>> Has anyone used Camel CDI in an OSGi environment?  Does it work well or
>> at
>>> least OK there?
>>> Brad

View raw message