[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