[cdi-dev] Adding / vetoing CDI extensions programmatically

[Mark Struberg]

You might look at DeltaSpikes ‚Deactivatable‘

LieGrue,
strub

> Am 01.10.2015 um 18:30 schrieb Antonin Stefanutti <antonin at stefanutti.fr>:
> 
> Hi CDI mates,
> 
> I’ve been developing a couple of CDI extensions over the last couple of years and been facing this recurrent situation:
> - I develop the extension against the latest CDI release version (1.2 for the time being),
> - As the extension gets used, comes the requests to run the extension in previous CDI versions,
> - As any real-world extensions heavily rely on the CDI SPI, they never happen to be backward-compatible,
> - And that’s understandable that the end-users won’t upgrade its runtime environment for just one extension.
> 
> One option is to rewrite the extension against the oldest required CDI version (generally 1.0 as a lot of people still use that version as part of Java EE 6) by working around lacking functionalities from the CDI SPI at the cost of code readability or even removed features that are impossible to re-implement.
> 
> To avoid that, it is obviously possible to create a separate branch / module dedicated to porting the extension to the oldest possible CDI version, but then comes the packaging / distribution problem:
> -  You assign different versions to the branches, unfortunately that does not work for projects that include their own CDI extension into the same codeline (like Apache Camel, JBoss Infinispan, …) as it doesn’t make sense to impact the whole project versioning for one possible container / runtime among others possible,
> - Or you create two artifacts / modules whose name (or classifier) somehow contains the CDI compatible version.
> 
> That’s not very ideal either, and in any case, that’s the end user burden to make the decision which artifact to choose from a list that will grow over time with CDI 2.0 and future CDI versions.
> 
> Which leads to my point... As there exists a way to add / veto annotated types and beans programmatically, one solution that will help addressing the above problems, both for the extension developers and users, would be to have the ability to add / veto extensions dynamically. That way, multiple version / part of the extension could be packaged into a single artifact and activated dynamically during the application initialisation phase based on some runtime criteria, in my use case the CDI environment version. The point here is not to discuss potential implementations, but we could imagine having an AfterExtensionDiscovery of BeforeTypeDiscovery lifecycle event from which adding or vetoing extensions would be possible, or some mechanisms in the beans.xml file to include / exclude an extension...
> 
> So before discussing implementation details, I’d like your opinion on that use case, whether it’s valid or other options exist.
> 
> Thanks,
> Antonin
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.