Here is the mail I sent a few weeks ago to ops4j about the pax-cdi changes During the last weeks, I worked on PAX CDI to solve some of the problems I had in trying to have camel-cdi (which uses deltaspike) working in Karaf.
For that, I changed quite a bit of things, mainly the way CDI bundles an extensions are packaged / discovered and extended. The main change is that CDI bundles now need to opt-in with the following manifest header: Require-Capability = osgi.extender; filter:="(osgi.extender=pax.cdi)" Extension bundles must advertise their extensions using Provide-Capability = org.ops4j.pax.cdi.extension; extension=deltaspike-core-impl And bean bundles requiring an extension have to specify it using Require-Capability = org.ops4j.pax.cdi.extension; filter:="(extension=deltaspike-core-impl)" Transitive extensions dependencies are discovered, so that in my case, I have camel-cdi providing an extension, but requiring deltaspike-core-impl and deltaspike-core-api. The OSGi resolver takes care about wiring the extensions to the bean bundle and the extender simply find the wired extensions and use them when creating the container. > On Tue, Mar 26, 2013 at 8:50 AM, Charles Moulliard < > [email protected] > > wrote: > > > Guillaume, > > > > Can you provide more info about How to use this change in the projects > > where we will use DS, pax-cdi, .... ? > > > > — > > Reply to this email directly or view it on GitHub< > https://github.com/apache/incubator-deltaspike/pull/1#issuecomment-15445386 > > > > . > > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ >
