[cdi-dev] Adding / vetoing CDI extensions programmatically
Mark Struberg
struberg at yahoo.de
Fri Oct 2 09:10:47 EDT 2015
We already discussed in that direction a long time ago. Check the comments in https://issues.jboss.org/browse/CDI-18.
The idea was to ‚merge‘ info in beans.xml where information with a higher ‚ordinal‘ (importance) overwrite information from a beans.xml with lower priority.
But we didn’t end up going in this direction yet but instead went with having @Priority on each and every class.
LieGrue,
strub
> Am 02.10.2015 um 10:31 schrieb Antonio Goncalves <antonio.goncalves at gmail.com>:
>
> 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> _______________________________________________
> 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.
More information about the cdi-dev
mailing list