[cdi-dev] Adding / vetoing CDI extensions programmatically

Thomas Andraschko andraschko.thomas at gmail.com
Fri Oct 2 05:05:23 EDT 2015


a global-beans.xml sounds like good way to add something to the CDI API
which is similiar to DeltaSpike global alternatives!


2015-10-02 10:54 GMT+02:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:

> 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.
>
>
> _______________________________________________
> 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/484cf0d7/attachment.html 


More information about the cdi-dev mailing list