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 <brad.john...@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 < > 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 > > > > > -- Charlie Mordant Full OSGI/EE stack made with Karaf: https://github.com/OsgiliathEnterprise/net.osgiliath.parent
