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