Re: [cdi-dev] Adding / vetoing CDI extensions programmatically

Interesting, couldn't excludes supports it? when processing extensions we have the beans.xml model so extensions could be filtered this way, no?

Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2015-10-01 13:44 GMT-07:00 arjan tijms <arjan.tijms(a)gmail.com <mailto:arjan.tijms@gmail.com>>: 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(a)stefanutti.fr <mailto:antonin@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(a)lists.jboss.org <mailto:cdi-dev@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. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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. _______________________________________________ cdi-dev mailing list cdi-dev(a)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.