[cdi-dev] Adding / vetoing CDI extensions programmatically

[Martin Kouba]

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