<div dir="ltr">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.<div><br></div><div>Antonio</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 2, 2015 at 9:59 AM, Martin Kouba <span dir="ltr"><<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dne 1.10.2015 v 22:55 Romain Manni-Bucau napsal(a):<br>
<span class="">> Interesting, couldn't excludes supports it? when processing extensions<br>
> we have the beans.xml model so extensions could be filtered this way, no?<br>
<br>
</span>No. beans.xml excludes are local (i.e. per bean archive). Extensions are<br>
global - per application.<br>
<br>
><br>
><br>
> Romain Manni-Bucau<br>
> @rmannibucau <<a href="https://twitter.com/rmannibucau" rel="noreferrer" target="_blank">https://twitter.com/rmannibucau</a>> | Blog<br>
> <<a href="http://rmannibucau.wordpress.com" rel="noreferrer" target="_blank">http://rmannibucau.wordpress.com</a>> | Github<br>
> <<a href="https://github.com/rmannibucau" rel="noreferrer" target="_blank">https://github.com/rmannibucau</a>> | LinkedIn<br>
> <<a href="https://www.linkedin.com/in/rmannibucau" rel="noreferrer" target="_blank">https://www.linkedin.com/in/rmannibucau</a>> | Tomitriber<br>
> <<a href="http://www.tomitribe.com" rel="noreferrer" target="_blank">http://www.tomitribe.com</a>><br>
<span class="">><br>
> 2015-10-01 13:44 GMT-07:00 arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a><br>
</span>> <mailto:<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>>>:<br>
<span class="">><br>
> There's an existing issue for this:<br>
> <a href="https://issues.jboss.org/browse/CDI-157" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-157</a><br>
><br>
> The JSF EG is also really interested in this, for<br>
> <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1361" rel="noreferrer" target="_blank">https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1361</a> and<br>
> several other things.<br>
><br>
> Kind regards,<br>
> Arjan Tijms<br>
><br>
><br>
> On Thu, Oct 1, 2015 at 6:30 PM, Antonin Stefanutti<br>
</span><div><div class="h5">> <<a href="mailto:antonin@stefanutti.fr">antonin@stefanutti.fr</a> <mailto:<a href="mailto:antonin@stefanutti.fr">antonin@stefanutti.fr</a>>> wrote:<br>
> > Hi CDI mates,<br>
> ><br>
> > I’ve been developing a couple of CDI extensions over the last<br>
> couple of<br>
> > years and been facing this recurrent situation:<br>
> > - I develop the extension against the latest CDI release version<br>
> (1.2 for<br>
> > the time being),<br>
> > - As the extension gets used, comes the requests to run the<br>
> extension in<br>
> > previous CDI versions,<br>
> > - As any real-world extensions heavily rely on the CDI SPI, they<br>
> never<br>
> > happen to be backward-compatible,<br>
> > - And that’s understandable that the end-users won’t upgrade its<br>
> runtime<br>
> > environment for just one extension.<br>
> ><br>
> > One option is to rewrite the extension against the oldest<br>
> required CDI<br>
> > version (generally 1.0 as a lot of people still use that version<br>
> as part of<br>
> > Java EE 6) by working around lacking functionalities from the CDI<br>
> SPI at the<br>
> > cost of code readability or even removed features that are<br>
> impossible to<br>
> > re-implement.<br>
> ><br>
> > To avoid that, it is obviously possible to create a separate<br>
> branch / module<br>
> > dedicated to porting the extension to the oldest possible CDI<br>
> version, but<br>
> > then comes the packaging / distribution problem:<br>
> > - You assign different versions to the branches, unfortunately<br>
> that does<br>
> > not work for projects that include their own CDI extension into<br>
> the same<br>
> > codeline (like Apache Camel, JBoss Infinispan, …) as it doesn’t<br>
> make sense<br>
> > to impact the whole project versioning for one possible container<br>
> / runtime<br>
> > among others possible,<br>
> > - Or you create two artifacts / modules whose name (or<br>
> classifier) somehow<br>
> > contains the CDI compatible version.<br>
> ><br>
> > That’s not very ideal either, and in any case, that’s the end<br>
> user burden to<br>
> > make the decision which artifact to choose from a list that will<br>
> grow over<br>
> > time with CDI 2.0 and future CDI versions.<br>
> ><br>
> > Which leads to my point... As there exists a way to add / veto<br>
> annotated<br>
> > types and beans programmatically, one solution that will help<br>
> addressing the<br>
> > above problems, both for the extension developers and users,<br>
> would be to<br>
> > have the ability to add / veto extensions dynamically. That way,<br>
> multiple<br>
> > version / part of the extension could be packaged into a single<br>
> artifact and<br>
> > activated dynamically during the application initialisation phase<br>
> based on<br>
> > some runtime criteria, in my use case the CDI environment<br>
> version. The point<br>
> > here is not to discuss potential implementations, but we could<br>
> imagine<br>
> > having an AfterExtensionDiscovery of BeforeTypeDiscovery<br>
> lifecycle event<br>
> > from which adding or vetoing extensions would be possible, or some<br>
> > mechanisms in the beans.xml file to include / exclude an extension...<br>
> ><br>
> > So before discussing implementation details, I’d like your<br>
> opinion on that<br>
> > use case, whether it’s valid or other options exist.<br>
> ><br>
> > Thanks,<br>
> > Antonin<br>
> ><br>
> > _______________________________________________<br>
> > cdi-dev mailing list<br>
</div></div>> > <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
<span class="">> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> ><br>
> > Note that for all code provided on this list, the provider<br>
> licenses the code<br>
> > under the Apache License, Version 2<br>
> > (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
> ideas<br>
> > provided on this list, the provider waives all patent and other<br>
> intellectual<br>
> > property rights inherent in such information.<br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
</span>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
<span class="im HOEnZb">> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses<br>
> the code under the Apache License, Version 2<br>
> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
> ideas provided on this list, the provider waives all patent and<br>
> other intellectual property rights inherent in such information.<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
><br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Antonio Goncalves <br>Software architect, Java Champion and Pluralsight author<br><br><a href="http://www.antoniogoncalves.org" target="_blank">Web site</a> | <a href="http://twitter.com/agoncal" target="_blank">Twitter</a> | <a href="http://www.linkedin.com/in/agoncal" target="_blank">LinkedIn</a> | <a href="http://pluralsight.com/training/Authors/Details/antonio-goncalves" target="_blank">Pluralsight</a> | <a href="http://www.parisjug.org" target="_blank">Paris JUG</a> | <a href="http://www.devoxx.fr" target="_blank">Devoxx France</a></div></div>
</div>