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 <cmorda...@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 <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 >
