[cdi-dev] Adding / vetoing CDI extensions programmatically

[Romain Manni-Bucau]

Interesting, couldn't excludes supports it? when processing extensions we
have the beans.xml model so extensions could be filtered this way, no?


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>:

> 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> 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
> > 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/20151001/5b6695ea/attachment.html