Re: [cdi-dev] Adding / vetoing CDI extensions programmatically
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(a)stefanutti.fr> a
écrit :
On 02 Oct 2015, at 10:54, Antoine Sabot-Durand <antoine(a)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(a)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(a)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
Attachments:
- attachment.html (text/html — 2.9 KB)