<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">Hi CDI mates,</span><br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">I’ve been developing a couple of CDI extensions over the last couple of years and been facing this recurrent situation:</span><br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">- I develop the extension against the latest CDI release version (1.2 for the time being),</span><br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">- As the extension gets used, comes the requests to run the extension in previous CDI versions,</span><br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">- As any real-world extensions heavily rely on the CDI SPI, they never happen to be backward-compatible,</span><br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">- And that’s understandable that the end-users won’t upgrade its runtime environment for just one extension.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">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.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">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:</span><br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">- &nbsp;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,</span><br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">- Or you create two artifacts / modules whose name (or classifier) somehow contains the CDI compatible version.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">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.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">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...</span><br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">So before discussing implementation details, I’d like your opinion on that use case, whether it’s valid or other options exist.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">Thanks,</span><br style="font-family: Menlo-Regular; font-size: 11px;" class="">
<span style="font-family: Menlo-Regular; font-size: 11px;" class="">Antonin</span>
</body>
</html>