[cdi-dev] Adding / vetoing CDI extensions programmatically

Antoine Sabot-Durand antoine at sabot-durand.net
Fri Oct 2 04:54:09 EDT 2015


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 at gmail.com>
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 at redhat.com> 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 at gmail.com
>> > <mailto:arjan.tijms at 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 at stefanutti.fr <mailto: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 <mailto: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.
>> >
>> >     _______________________________________________
>> >     cdi-dev mailing list
>> >     cdi-dev at lists.jboss.org <mailto: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.
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > 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.
>> >
>>
>> --
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic
>> _______________________________________________
>> 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.
>>
>
>
>
> --
> 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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151002/4eb9dac2/attachment-0001.html 


More information about the cdi-dev mailing list