[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