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/22 14:33:40 UTC
Camel CDI
Has anyone used Camel CDI in an OSGi environment? Does it work well or at
least OK there?
Brad
Re: Camel CDI
Posted by Brad Johnson <br...@mediadriver.com>.
By the way, I do confess some confusion about a bundle scoped OSGi
service. Seems that one can just use the regular injection in that case if
I'm understanding. In any case this gets me everything I want from easy
development with XML and easy unit tests and integration tests through Pax
Exam. Excellent work guys.
@OsgiServiceProvider
@BundleScoped
public class ChocolateService implements IceCreamService {
}
https://ops4j1.jira.com/wiki/display/PAXCDI/Cheat+Sheet
Brad
On Mon, Aug 22, 2016 at 10:52 AM, Brad Johnson <brad.johnson@mediadriver.com
> wrote:
> Antonin,
>
> Ah, OK, that explains it. That's why I'm seeing Weld, it's just for the
> unit tests. That's fine. The Camel CDI web page actually does say that
> Karaf uses CDI 1.2 and pax-cdi so that now makes more sense.
>
> Brad
>
> On Mon, Aug 22, 2016 at 10:45 AM, Charlie Mordant <cm...@gmail.com>
> wrote:
>
>> Hi,
>>
>> Osgiliath enterprise framework is using a combination of camel-cdi and
>> pax-cdi: it works pretty well ;).
>>
>> Please take a look at this integration test module:
>> https://github.com/OsgiliathEnterprise/net.osgiliath.parent/
>> tree/master/net.osgiliath.framework/net.osgiliath.features/net.osgiliath.
>> features.itests/net.osgiliath.feature.itest.messaging
>>
>> Regards,
>>
>>
>> 2016-08-22 17:26 GMT+02:00 Brad Johnson <br...@mediadriver.com>:
>>
>> > 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 <
>> > antonin@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.johnson@mediadriver.com>
>> > > wrote:
>> > > >
>> > > > Has anyone used Camel CDI in an OSGi environment? Does it work
>> well or
>> > > at
>> > > > least OK there?
>> > > >
>> > > > Brad
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> Charlie Mordant
>>
>> Full OSGI/EE stack made with Karaf:
>> https://github.com/OsgiliathEnterprise/net.osgiliath.parent
>>
>
>
Re: Camel CDI
Posted by Brad Johnson <br...@mediadriver.com>.
Antonin,
Ah, OK, that explains it. That's why I'm seeing Weld, it's just for the
unit tests. That's fine. The Camel CDI web page actually does say that
Karaf uses CDI 1.2 and pax-cdi so that now makes more sense.
Brad
On Mon, Aug 22, 2016 at 10:45 AM, Charlie Mordant <cm...@gmail.com>
wrote:
> Hi,
>
> Osgiliath enterprise framework is using a combination of camel-cdi and
> pax-cdi: it works pretty well ;).
>
> Please take a look at this integration test module:
> https://github.com/OsgiliathEnterprise/net.osgiliath.parent/tree/master/
> net.osgiliath.framework/net.osgiliath.features/net.
> osgiliath.features.itests/net.osgiliath.feature.itest.messaging
>
> Regards,
>
>
> 2016-08-22 17:26 GMT+02:00 Brad Johnson <br...@mediadriver.com>:
>
> > 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 <
> > antonin@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.johnson@mediadriver.com
> >
> > > wrote:
> > > >
> > > > Has anyone used Camel CDI in an OSGi environment? Does it work well
> or
> > > at
> > > > least OK there?
> > > >
> > > > Brad
> > >
> > >
> >
>
>
>
> --
> Charlie Mordant
>
> Full OSGI/EE stack made with Karaf:
> https://github.com/OsgiliathEnterprise/net.osgiliath.parent
>
Re: Camel CDI
Posted by Charlie Mordant <cm...@gmail.com>.
Hi,
Osgiliath enterprise framework is using a combination of camel-cdi and
pax-cdi: it works pretty well ;).
Please take a look at this integration test module:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent/tree/master/net.osgiliath.framework/net.osgiliath.features/net.osgiliath.features.itests/net.osgiliath.feature.itest.messaging
Regards,
2016-08-22 17:26 GMT+02:00 Brad Johnson <br...@mediadriver.com>:
> 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 <
> antonin@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 <br...@mediadriver.com>
> > wrote:
> > >
> > > Has anyone used Camel CDI in an OSGi environment? Does it work well or
> > at
> > > least OK there?
> > >
> > > Brad
> >
> >
>
--
Charlie Mordant
Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent
Re: Camel CDI
Posted by Antonin Stefanutti <an...@stefanutti.fr>.
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.
[1]: https://github.com/apache/camel/blob/0421c24dfcf992f3296ed746469771e3800200e3/components/camel-cdi/src/main/java/org/apache/camel/cdi/CamelContextOsgiProducer.java#L32
Antonin
> On 22 Aug 2016, at 17:26, Brad Johnson <br...@mediadriver.com> 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>
> <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 <an...@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 <br...@mediadriver.com>
>> wrote:
>>>
>>> Has anyone used Camel CDI in an OSGi environment? Does it work well or
>> at
>>> least OK there?
>>>
>>> Brad
>>
>>
Re: Camel CDI
Posted by Brad Johnson <br...@mediadriver.com>.
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 <an...@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 <br...@mediadriver.com>
> wrote:
> >
> > Has anyone used Camel CDI in an OSGi environment? Does it work well or
> at
> > least OK there?
> >
> > Brad
>
>
Re: Camel CDI
Posted by Antonin Stefanutti <an...@stefanutti.fr>.
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 <br...@mediadriver.com> wrote:
>
> Has anyone used Camel CDI in an OSGi environment? Does it work well or at
> least OK there?
>
> Brad