deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [incubator-deltaspike] [DELTASPIKE-316] Upgrade to latest pax-cdi requirements for cdi extensions (#1)
Date Tue, 26 Mar 2013 08:05:56 GMT
Here is the mail I sent a few weeks ago 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 and
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;

And bean bundles requiring an extension have to specify it using
   Require-Capability = org.ops4j.pax.cdi.extension;

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

Guillaume Nodet
Red Hat, Open Source Integration


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message