[cdi-dev] Adding / vetoing CDI extensions programmatically

[arjan tijms]

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

The JSF EG is also really interested in this, for
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1361 and
several other things.

Kind regards,
Arjan Tijms


On Thu, Oct 1, 2015 at 6:30 PM, Antonin Stefanutti
<antonin at stefanutti.fr> wrote:
> 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.