Am 01.10.2015 um 18:30 schrieb Antonin Stefanutti <antonin(a)stefanutti.fr&gt;: 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 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.

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&gt; 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 > 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.

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.

I think the idea of a global configuration, either in a global-beans.xml, either in the code ((ProcessExtensions or AfterExtensionDiscovery ;)) is an interesting topic. Now this doesn't solve the problem for existing version : no obvious way to remove a 2.0 extension in 1.2 code... Antoine Le ven. 2 oct. 2015 à 10:32, Antonio Goncalves < antonio.goncalves(a)gmail.com&gt; a écrit : > 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. _______________________________________________ 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.

On 02 Oct 2015, at 10:54, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: Now this doesn't solve the problem for existing version : no obvious way to remove a 2.0 extension in 1.2 code… I thought about that too and, in my use case at least, that would be fine if: - Extension for CDI version < 2.0 use the default service provider mechanism, - Extension for CDI version >= 2.0 does not use the service provider mechanism, - In CDI runtime version >= 2.0 the old version is deactivated programatically while the new version is added programmatically. On 01 Oct 2015, at 21:15, Mark Struberg <struberg(a)yahoo.de&gt; wrote: You might look at DeltaSpikes ‚Deactivatable‘ Thanks. I’d be very interested in what mechanism is used to prevent the container from loading the extension? On 01 Oct 2015, at 22:44, arjan tijms <arjan.tijms(a)gmail.com&gt; wrote: There's an existing issue for this: https://issues.jboss.org/browse/CDI-157 Thanks. Looks like this is a generic need, though pretty advanced. We’ll be able to track the outcome of this discussion in that ticket then. Antonin

Am 02.10.2015 um 10:31 schrieb Antonio Goncalves <antonio.goncalves(a)gmail.com&gt;: 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France _______________________________________________ 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.