[cdi-dev] Adding / vetoing CDI extensions programmatically

Antonio Goncalves antonio.goncalves at gmail.com
Fri Oct 2 04:31:51 EDT 2015


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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151002/ae3052fd/attachment.html 


More information about the cdi-dev mailing list