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

BTW during the F2F meeting we discussed the idea of having a "global" beans.xml (the same idea behind web.xml and web-fragment.xml). So the idea is to be able to include/exclude globally. Antonio On Fri, Oct 2, 2015 at 9:59 AM, Martin Kouba <mkouba(a)redhat.com&gt; wrote: > Dne 1.10.2015 v 22:55 Romain Manni-Bucau napsal(a): > > Interesting, couldn't excludes supports it? when processing extensions > > we have the beans.xml model so extensions could be filtered this way, > no? > > No. beans.xml excludes are local (i.e. per bean archive). Extensions are > global - per application. > > > > > > > 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. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > 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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site <http://www.antoniogoncalves.org> | Twitter <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr> _______________________________________________ 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.