There's a solution at implementation level. Since extension developed for 1.2 contains unknown classes in 1.0, the impl could catch the "class not found" exception on an extension send a warning to user and don't use the extension. In other way instead of letting the app crash, manage the crash by ignoring the extension.

Antoine

Le ven. 2 oct. 2015 à 11:20, Antonin Stefanutti <antonin@stefanutti.fr> a écrit :

On 02 Oct 2015, at 10:54, Antoine Sabot-Durand <antoine@sabot-durand.net> wrote:

Now this doesn't solve the problem for existing version : no obvious way to remove a 2.0 extension in 1.2 code…

I thought about that too and, in my use case at least, that would be fine if:

- Extension for CDI version < 2.0 use the default service provider mechanism,

- Extension for CDI version >= 2.0 does not use the service provider mechanism,

- In CDI runtime version >= 2.0 the old version is deactivated programatically while the new version is added programmatically.

On 01 Oct 2015, at 21:15, Mark Struberg <struberg@yahoo.de> wrote:

You might look at DeltaSpikes ‚Deactivatable‘

Thanks. I’d be very interested in what mechanism is used to prevent the container from loading the extension?

On 01 Oct 2015, at 22:44, arjan tijms <arjan.tijms@gmail.com> wrote:

There's an existing issue for this: https://issues.jboss.org/browse/CDI-157

Thanks. Looks like this is a generic need, though pretty advanced. We’ll be able to track the outcome of this discussion in that ticket then.

Antonin