[cdi-dev] Adding / vetoing CDI extensions programmatically

[Antoine Sabot-Durand]

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 at stefanutti.fr> a
écrit :

>
> On 02 Oct 2015, at 10:54, Antoine Sabot-Durand <antoine at 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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151002/2633e9e6/attachment.html