http://www.cdi-spec.org/Contexts and Dependency Injection2020-09-18T09:00:18+02:00http://www.cdi-spec.org/news/2020/09/15/CDI_Lite_extension.htmlBuild Compatible Extensions Proposal2020-09-18T09:00:18+02:002020-09-15T00:00:00+00:00
A few months back we shared our vision for CDI lite.
In short, the goal with CDI lite is to make the spec lighter, cloud-friendlier and allow for build-time implementations which are now on the rise.
When we started thinking about a “lite” variant of CDI, amenable to build-time processing, we understood that an alternative to Portable Extensions is necessary. Subsequent discussion on the MicroProfile mailing list confirmed that.
We explored several variants of how the API might look like. This blog post shows one that, we believe, has the most potential. We call it Build Compatible Extensions, but the name, as everything...
<div class="paragraph">
<p>A few months back we shared our vision for CDI lite.
In short, the goal with CDI lite is to make the spec lighter, cloud-friendlier and allow for build-time implementations which are now on the rise.</p>
</div>
<div class="paragraph">
<p>When we started thinking about a “lite” variant of CDI, amenable to build-time processing, we understood that an alternative to Portable Extensions is necessary. Subsequent discussion on the MicroProfile mailing list confirmed that.</p>
</div>
<div class="paragraph">
<p>We explored several variants of how the API might look like. This blog post shows one that, we believe, has the most potential. We call it <em>Build Compatible Extensions</em>, but the name, as everything else described here, is up for debate.</p>
</div>
<div class="paragraph">
<p>For our explorations of the API design space, we mostly constrained ourselves to one particularly common use case: annotation transformations. Many things that Portable Extensions allow can be achieved simply by adding an annotation here or removing an annotation there. We know that other transformations are necessary, but the API for annotation transformation is the most developed proposal we have. The other ones are significantly more rough, so bear with us please and submit feedback!
You can do that in form of a GitHub issue against the <a href="https://github.com/eclipse-ee4j/cdi/issues">CDI repository</a> and add the <code>lite-extension-api</code> label to your issue.</p>
</div>
<div class="paragraph">
<p>Before we start, we’d also like to note that in this text, we assume the reader (that is, you!) is familiar with CDI and preferably also Portable Extensions, as we expect some knowledge and don’t explain everything. We also make references to Portable Extensions on several occasions.</p>
</div>
<div class="sect1">
<h2 id="extensions"><a class="anchor" href="#extensions" />Extensions</h2>
<div class="sectionbody">
<div class="paragraph">
<p>In our proposal, Build Compatible Extensions are simply methods annotated with an <em>extension annotation</em>. Extension annotations correspond to phases in which extensions are processed. There are 4 phases:</p>
</div>
<div class="olist arabic">
<ol class="arabic">
<li>
<p><strong>@Discovery</strong>: adding classes to application, registering custom contexts</p>
</li>
<li>
<p><strong>@Enhancement</strong>: transforming annotations</p>
</li>
<li>
<p><strong>@Synthesis</strong>: registering synthetic beans and observers</p>
</li>
<li>
<p><strong>@Validation</strong>: performing custom validation</p>
</li>
</ol>
</div>
<div class="paragraph">
<p>There are some constraints we put on these methods (such as: they must be <code>public</code>), but they should be pretty obvious and shouldn’t be limiting anyone. The container automatically finds extensions and invokes them when time is right.
When exactly are the extensions invoked can’t be defined in too much detail, because we want implementations to be able to invoke them at build time (e.g. during application compilation) or runtime (e.g. during application deployment). It certainly happens before the application starts. Extensions in earlier phases are guaranteed to run before extensions in later phases.</p>
</div>
<div class="paragraph">
<p>Extensions can declare an arbitrary number of parameters, all of which are supplied by the container. There’s a set of predefined types of parameters for each phase, and all implementations would have to support that. We’re also thinking of designing an SPI that would allow anyone to contribute support for other types of parameters.
A class can declare multiple extension methods, in which case they are all invoked on a single instance of the class. If you need to control order of extension invocations, there’s an annotation <strong><code>@ExtensionPriority</code></strong> just for that.
This is a lot of text already, so let’s take a look at an example:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">public class MyExtension {
@Enhancement
public void doSomething() {
System.out.println("This is an extension, yay!");
}
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>This doesn’t really do anything, just prints a message whenever the extension is executed. Let’s create something more interesting. Say, moving a qualifier annotation from one class to another. Let’s assume that we have these classes in our application.</p>
</div>
<div class="sect2">
<h3 id="a-qualifier-annotation"><a class="anchor" href="#a-qualifier-annotation" />A qualifier annotation:</h3>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">@Qualifier
@Retention(RUNTIME)
@interface MyQualifier {
}</code></pre>
</div>
</div>
</div>
<div class="sect2">
<h3 id="a-service-interface"><a class="anchor" href="#a-service-interface" />A service interface:</h3>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">interface MyService {
String hello();
}</code></pre>
</div>
</div>
</div>
<div class="sect2">
<h3 id="two-implementations-one-with-qualifier-and-the-other-unqualified"><a class="anchor" href="#two-implementations-one-with-qualifier-and-the-other-unqualified" />Two implementations, one with qualifier and the other unqualified:</h3>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">@Singleton
@MyQualifier
class MyFooService implements MyService {
@Override
public String hello() {
return "foo";
}
}
@Singleton
class MyBarService implements MyService {
@Override
public String hello() {
return "bar";
}
}</code></pre>
</div>
</div>
</div>
<div class="sect2">
<h3 id="a-class-that-uses-the-service"><a class="anchor" href="#a-class-that-uses-the-service" />A class that uses the service</h3>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">@Singleton
class MyServiceUser {
@Inject
@MyQualifier
MyService myService;
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>Here, it’s pretty clear that when the CDI container instantiates the <code>MyServiceUser</code> class, it will inject a <code>MyFooService</code> into the <code>myService</code> field.
With a simple Build Compatible Extension, we can “transfer” the qualifier annotation from <code>MyFooService</code> to <code>MyBarService</code>:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">class MyExtension {
@Enhancement
public void configure(ClassConfig<MyFooService> foo,
ClassConfig<MyBarService> bar) {
foo.removeAnnotation(it -> it.name()
.equals(MyQualifier.class.getName()));
bar.addAnnotation(MyQualifier.class);
}
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>I’m sure you understand the extension pretty well already: with this extension present in the application, the CDI container will consider the <code>MyFooService</code> <em>not</em> annotated <code>@MyQualifier</code>, and at the same time, it will consider the <code>MyBarService</code> annotated <code>@MyQualifier</code>. In the end, <code>MyServiceUser.myService</code> will no longer hold a <code>MyFooService</code>; it will hold a <code>MyBarService</code> instead. We have successfully “moved” an annotation from one class to another, thereby altering how the CDI container behaves.</p>
</div>
<div class="paragraph">
<p>This is a very simple example, but using the exact same API, one can achieve many things. For example, if the CDI container doesn’t treat all classes as beans (in CDI Lite, this isn’t required), all it takes to create a bean out of a class is just adding a bean defining annotation:
<code>myClass.addAnnotation(Singleton.class);</code>
To “veto” a class, again, just add an annotation:
<code>myClass.addAnnotation(Vetoed.class);</code>
Etc. etc. etc.</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="extension-parameters"><a class="anchor" href="#extension-parameters" />Extension parameters</h2>
<div class="sectionbody">
<div class="paragraph">
<p>By now, you should have a general idea of how extensions look like. If you want to know the gory details, read on – but be warned, this is going to be long. You might want to skip directly to the conclusion at the end.
Still here? Good! As we said above, an extension can declare an arbitrary number of parameters. The parameters are where extensions become interesting, so let’s describe in detail which parameters can extensions declare.</p>
</div>
<div class="sect2">
<h3 id="code-discovery-code"><a class="anchor" href="#code-discovery-code" /><code>@Discovery</code></h3>
<div class="paragraph">
<p>Just two parameters are possible: <code>AppArchiveBuilder</code> to register custom classes so that the CDI container treats them as part of the application, and <code>Contexts</code> to register custom contexts.</p>
</div>
</div>
<div class="sect2">
<h3 id="code-enhancement-code"><a class="anchor" href="#code-enhancement-code" /><code>@Enhancement</code></h3>
<div class="paragraph">
<p>As mentioned above, we have focused mostly on this phase. Therefore, we have a pretty elaborate API which allows inspecting and modifying the application’s annotations.</p>
</div>
<div class="sect3">
<h4 id="inspecting-code"><a class="anchor" href="#inspecting-code" />Inspecting code</h4>
<div class="paragraph">
<p>You can look at all the classes, methods and fields in an application, and make decisions based on your findings. For that, an extension can declare parameters of these types:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code>ClassInfo<MyService></code>: to look at one particular class</p>
</li>
<li>
<p><code>Collection<ClassInfo<? extends MyService>></code>: to look at all subclasses</p>
</li>
<li>
<p><code>Collection<ClassInfo<? super MyService>></code>: to look at all superclasses</p>
</li>
<li>
<p><code>Collection<ClassInfo<?>></code>: to look at all classes</p>
</li>
<li>
<p><code>Collection<MethodInfo<MyService>></code>: to look at all methods declared on one class</p>
</li>
<li>
<p><code>Collection<MethodInfo<? extends MyService>></code>: to look at all methods declared on all subclasses</p>
</li>
<li>
<p><code>Collection<MethodInfo<? super MyService>></code>: to look at all methods declared on all superclasses</p>
</li>
<li>
<p><code>Collection<MethodInfo<?>></code>: to look at all methods declared on all classes</p>
</li>
<li>
<p><code>Collection<FieldInfo<MyService>></code>: to look at all fields declared on one class</p>
</li>
<li>
<p><code>Collection<FieldInfo<? extends MyService>></code>: to look at all fields declared on all subclasses</p>
</li>
<li>
<p><code>Collection<FieldInfo<? super MyService>></code>: to look at all fields declared on all superclasses</p>
</li>
<li>
<p><code>Collection<FieldInfo<?>></code>: to look at all fields declared on all classes</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Such parameters can also be annotated <code>@WithAnnotations</code>, in which case, only those classes/methods/fields annotated with given annotations will be provided.
The <code>ClassInfo</code>, <code>MethodInfo</code> and <code>FieldInfo</code> types give you visibility into all interesting details about given declarations. You can drill down to method parameters, their types, annotations, and so on.</p>
</div>
</div>
<div class="sect3">
<h4 id="the-new-metamodel"><a class="anchor" href="#the-new-metamodel" />The new metamodel</h4>
<div class="paragraph">
<p>Actually, let’s take a small detour to explain these <code>ClassInfo</code>, <code>MethodInfo</code> and <code>FieldInfo</code> types, because they totally deserve it.
You will note that they are actually very similar to the Java Reflection API. However, they do not rely on the Reflection API in any way, unlike the types in Portable Extensions. This is an important goal of the entire CDI Lite effort: make it possible to implement CDI completely at build time. To that end, we designed a completely new metamodel for Java classes, which can be implemented solely on top of Java bytecode.
The type hierarchy looks like this: at the top, there’s an <code>AnnotationTarget</code>. That’s basically anything that can be annotated. In Java, this means <em>declarations</em>, such as classes or methods, and <em>types</em>, such as a type of a method parameter. The <code>AnnotationTarget</code> lets you look at its annotations using these 4 methods:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">boolean hasAnnotation(Class<? extends Annotation> annotationType);
AnnotationInfo annotation(Class<? extends Annotation> annotationType);
Collection<AnnotationInfo> repeatableAnnotation(
Class<? extends Annotation> annotationType);
Collection<AnnotationInfo> annotations();</code></pre>
</div>
</div>
<div class="paragraph">
<p>The method <code>hasAnnotation(...)</code> returns whether a given annotation target (such as a class) has an annotation of given type. The <code>annotation(...)</code> method returns information about an annotation of a given type present on a given target (we’ll see more about <code>AnnotationInfo</code> soon). The <code>repeatableAnnotation(...)</code> method returns all annotations of a given repeatable annotation type, and finally the <code>annotations()</code> method returns all annotations present on a given target.
Let’s stop for a short example. Let’s say we have a <code>ClassInfo</code> for the <code>MyServiceUser</code> class, which we’ve seen in the previous example. We can do all kinds of interesting things with it, but here, let’s just check if the class has a <code>@Singleton</code> annotation, and if so, print all annotations on all fields annotated <code>@Inject</code>:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">ClassInfo<MyServiceUser> clazz = ...;
if (clazz.hasAnnotation(Singleton.class)) { // we know this is true
for (FieldInfo<MyServiceUser> field : clazz.fields()) {
if (field.hasAnnotation(Inject.class)) {
field.annotations().forEach(System.out::println);
}
}
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>You might have noticed that the <code>ClassInfo</code>, <code>MethodInfo</code> and <code>FieldInfo</code> types have a type parameter. This is only useful when declaring an extension parameter – there, it expresses a query (such as: give me all fields declared on all subclasses of <code>MyService</code>). In all other cases, it can be pretty much ignored.
Short tour through the <code>AnnotationInfo</code> type: you can access the <code>target()</code> of the annotation, as well as the annotation <code>declaration()</code>, and you can see the annotation attributes using the <code>hasAttribute(String)</code> and <code>attribute(String)</code> methods. Given that an attribute named <code>value</code> is particularly common, there’s also <code>hasValue()</code> and <code>value()</code>. And finally, there’s <code>attributes()</code> to access all annotation attributes at once. Annotation attributes are represented by the <code>AnnotationAttribute</code> interface, which has a <code>name()</code> and a <code>value()</code>. The attribute value is represented by <code>AnnotationAttributeValue</code>, which allows figuring out the actual type of the value, as well as obtaining its representation as an ordinary Java type.
As mentioned above, there are two kinds of <code>AnnotationTarget`s: declarations and types. Therefore, we have `DeclarationInfo</code> as the top-level type for representing Java declarations, and <code>Type</code> as the top-level type for representing Java types. To distinguish between them, the <code>AnnotationTarget</code> interface has 4 methods:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">boolean isDeclaration();
boolean isType();
DeclarationInfo asDeclaration();
Type asType();</code></pre>
</div>
</div>
<div class="paragraph">
<p>The <code>boolean</code>-returning methods return whether a given annotation target is a declaration or a type, and the remaining two methods cast to the corresponding type (or throw an exception). You can find similar methods on <code>DeclarationInfo</code> and <code>Type</code>, for various kinds of declarations and types (for example, <code>DeclarationInfo</code> has <code>isClass()</code>, <code>asClass()</code> and others).
We represent 4 kinds of Java declarations in the new metamodel: classes, methods (including constructors), method parameters, and fields. We’re thinking about if it’s worth adding a representation for packages, given that they can also be annotated (using <code>package-info.java</code>). Any opinion here is welcome!
Classes are represented by <code>ClassInfo</code>, which gives access to the <code>name()</code>, <code>superClass()</code>, all implemented <code>superInterfaces()</code>, all <code>typeParameters()</code>, and most importantly, all <code>constructors()</code>, <code>methods()</code> and <code>fields()</code>.
Constructors and methods are represented by <code>MethodInfo</code>, which gives access to the <code>name()</code>, <code>parameters()</code>, <code>returnType()</code> and also <code>typeParameters()</code>.
Method parameters are represented by <code>ParameterInfo</code>, which gives access to the <code>name()</code>, if it’s present (remember that parameter names don’t have to be present in bytecode!), and the <code>type()</code>.
Finally, fields are represented by <code>FieldInfo</code>, which gives access to <code>name()</code> and <code>type()</code>.
As you’ve surely noticed, we can often get hold of a type of something (method return type, field type, etc.). That’s a second kind of <code>AnnotationTarget</code>. As we’ve mentioned, the top-level representation of types is the <code>Type</code> interface, and there are 7 kinds of types: <code>VoidType</code>, <code>PrimitiveType</code>, <code>ClassType</code>, <code>ArrayType</code>, <code>ParameterizedType</code>, <code>TypeVariable</code> and <code>WildcardType</code>. We won’t go into details about these, as the text is already getting rather long.
Instead, let’s get back to extension parameters!</p>
</div>
</div>
<div class="sect3">
<h4 id="modifying-code"><a class="anchor" href="#modifying-code" />Modifying code</h4>
<div class="paragraph">
<p>Not only can you look at classes, methods and fields in your extension, you can also modify them. These modifications include adding and removing annotations, and are only considered by the CDI container. That is, the rest of the application will <em>not</em> see these modifications!
For each parameter type mentioned above, such as <code>ClassInfo<MyService></code> or <code>Collection<MethodInfo<? extends MyService>></code>, you can also declare a parameter of the corresponding <code>*Config</code> type: <code>ClassConfig<MyService></code>, <code>Collection<MethodConfig<? extends MyService>></code> etc.
Again you can use <code>@WithAnnotations</code> to narrow down the set of provided objects. Also, <code>ClassConfig</code> is actually a subtype of <code>ClassInfo</code>, so if you need to check a class before you configure it, having a <code>ClassConfig</code> is enough. <code>MethodConfig</code> and <code>FieldConfig</code> are similar.
The annotation configuration methods provided by these types are:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">void addAnnotation(Class<? extends Annotation> clazz,
AnnotationAttribute... attributes);
void addAnnotation(ClassInfo<?> clazz,
AnnotationAttribute... attributes);
void addAnnotation(AnnotationInfo annotation);
void addAnnotation(Annotation annotation);
void removeAnnotation(Predicate<AnnotationInfo> predicate);
void removeAllAnnotations();</code></pre>
</div>
</div>
<div class="paragraph">
<p>While technically, we could do with just 2 methods, one for adding and one for removing annotations, we decided to have 6 of them to give extension implementations more flexibility. For example, you can use `AnnotationLiteral`s when adding an annotation, similarly to Portable Extensions, but you don’t have to.</p>
</div>
</div>
<div class="sect3">
<h4 id="other-types"><a class="anchor" href="#other-types" />Other types</h4>
<div class="paragraph">
<p>While it’s possible to declare a parameter of type <code>Collection<ClassInfo<?>></code>, it’s very likely that you don’t want to do this. It’s a sign that you need to do a more elaborate processing, for which the simple declarative API is not powerful enough. Luckily, we have an imperative entrypoint as well: <code>AppArchive</code>. With this, you can programmatically construct queries to find classes, methods and fields. If you also want to configure the classes, methods or fields, you can use <code>AppArchiveConfig</code>, which extends <code>AppArchive</code>. For example:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">public class MyExtension {
@Enhancement
public void configure(AppArchiveConfig app) {
app.classes()
.subtypeOf(MyService.class)
.configure()
.stream()
.filter(it -> !it.hasAnnotation(MyAnnotation.class))
.forEach(it -> it.addAnnotation(MyAnnotation.class));
}
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>Again, you can search for classes, methods and fields, based on where they are declared or what annotations they have. For classes, <code>AppArchive</code> gives you access to a collection of <code>ClassInfo</code> and <code>AppArchiveConfig</code> gives you access to a collection of <code>ClassConfig</code>. Similarly for methods and fields.
Above, we have seen a simple way of adding annotations. There are more elaborate ways for advanced use cases, for which you need to create instances of <code>AnnotationAttribute</code> or <code>AnnotationAttributeValue</code>. In such a case, an extension can declare a parameter of type <code>Annotations</code>, which is essentially a factory for these types.
Similarly, you can declare a parameter of type <code>Types</code>, which serves as a factory for instances of <code>Type</code>.</p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="synthesis"><a class="anchor" href="#synthesis" />@Synthesis</h3>
<div class="paragraph">
<p>The most important parameter type you can declare for extensions in this phase is <code>SyntheticComponents</code>. It allows you to register synthetic beans and observers. Note that this API has one significant unsolved problem: how to define the construction and destruction function for synthetic beans, or the observer function for synthetic observers. This needs to work at build time, so we’re entering the realm of bytecode generation and similar fun topics. We have some ideas here, and we’ll work on adding them to the API proposal.
You can also declare all the parameters that give you access to <code>ClassInfo</code>, <code>MethodInfo</code> and <code>FieldInfo</code>, as described above, including <code>AppArchive</code>. What’s more interesting, you can also inspect existing beans and observers in the application. This is very similar to inspecting classes, methods and fields, so let’s take it quickly.
You can declare a parameter of type <code>Collection<BeanInfo<? super MyService>></code> to obtain information about all beans in the application that have <code>MyService</code> or any of its supertypes as one of the bean types. (Note that this example is not very useful, as <code>Object</code> is one of the supertypes of <code>MyService</code>, and all beans typically have <code>Object</code> as one of their types.) Similarly, you can declare a parameter of type <code>Collection<ObserverInfo<? extends MyEvent>></code> to obtain information about all observers in the application that observe <code>MyEvent</code> or any of its subtypes. All the other combinations are of course also possible, and if that is not enough, there’s <code>AppDeployment</code>, which gives you more powerful querying features, similarly to <code>AppArchive</code>. You can find beans based on their scope, types, qualifiers, or the declaring class. Similarly with observers, you can filter on the observed type, qualifiers, or the declaring class.</p>
</div>
</div>
<div class="sect2">
<h3 id="validation"><a class="anchor" href="#validation" />@Validation</h3>
<div class="paragraph">
<p>The most important parameter type you can declare for extensions in this phase is <code>Errors</code>. It allows you to add custom validation errors.
What can you validate? Pretty much anything. You can get access to classes, methods and fields, just like in the <code>@Enhancement</code> phase, and you can also get access to beans and observers, just like in the <code>@Synthesis</code> phase. This includes both the <code>Collection<SomethingInfo<...>></code> approach, and <code>AppArchive</code> / <code>AppDeployment</code> way.
Error messages can be simple <code>String`s, optionally accompanied by a `DeclarationInfo</code>, <code>BeanInfo</code> or <code>ObserverInfo</code>, or arbitrary `Exception`s.
In case a validation error is added, the container will prevent the application from successfully deploying (or even building, in case of build time implementations).</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="conclusion"><a class="anchor" href="#conclusion" />Conclusion</h2>
<div class="sectionbody">
<div class="paragraph">
<p>You have just finished a deep dive into our current Build Compatible Extensions API proposal.</p>
</div>
<div class="paragraph">
<p>Together with the API proposal, we also developed a proof-of-concept implementation in Quarkus, so that we know this API can be implemented, and that it is indeed build-time compatible. This proof of concept focuses solely on the <code>@Enhancement</code> phase, but that should be enough for now. It’s also worth noting that there is nothing Quarkus specific about the API. We believe (and our goal) is that any CDI-Lite implementation could adopt it using a variety of implementation strategies.</p>
</div>
<div class="paragraph">
<p>We’re publishing the Quarkus fork in the form of a GitHub repository so that you can also experiment with it. Please bear in mind that the POC implementation is very rough and definitely is not production ready. It should be enough to evaluate the API proposal, though. Here’s how you can get your hands on it:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-console" data-lang="console">git clone https://github.com/Ladicek/quarkus-fork.git
cd quarkus-fork
git checkout experiment-cdi-lite-ext
./mvnw -Dquickly</code></pre>
</div>
</div>
<div class="paragraph">
<p>Wait a few minutes or more, depending on how many Quarkus dependencies you already have in your local Maven repository. When the build finishes, you can add a dependency on <code>io.quarkus.arc:cdi-lite-ext-api:999-SNAPSHOT</code> to your project and play. Don’t forget to also bump other Quarkus dependencies, as well as the Quarkus Maven plugin, to <code>999-SNAPSHOT</code>!
As mentioned before, we are very keen on hearing your feedback. Please file issues in the <a href="https://github.com/eclipse-ee4j/cdi/issues">CDI GitHub repository</a> with label <code>lite-extension-api</code>. Let’s work together on making these new Build Compatible Extensions a reality!</p>
</div>
</div>
</div>
http://www.cdi-spec.org/news/2020/03/09/CDI_for_the_future.htmlCDI for the future2020-09-18T08:53:43+02:002020-03-09T00:00:00+00:00
A few months ago, CDI turned 10! Yes, CDI 1.0 was released 10 years ago and is today one of the most successful specifications in Java EE and now Jakarta EE. Providing a very efficient programming model and elegant means to integrate with 3rd party technology it rapidly became the Java EE cornerstone. As other specifications were adopting its programming model, CDI brought a unified way to write Java EE code and made the platform more consistent than before. So when MicroProfile was launched nearly four years ago, it was obvious that CDI should be part of the core...
<div class="imageblock" style="float: right">
<div class="content">
<img src="http://www.cdi-spec.org/images/inside_quark_web.jpg" alt="inside quark web" width="285">
</img>
</div>
<div class="paragraph">
<p>A few months ago, CDI turned 10! Yes, CDI 1.0 was released 10 years ago and is today one of the most successful specifications in Java EE and now Jakarta EE. Providing a very efficient programming model and elegant means to integrate with 3rd party technology it rapidly became the Java EE cornerstone. As other specifications were adopting its programming model, CDI brought a unified way to write Java EE code and made the platform more consistent than before. So when MicroProfile was launched nearly four years ago, it was obvious that CDI should be part of the core platform along with JAX-RS and JSON-P. Today, MicroProfile programming model relies deeply on CDI and the platform success is partly due to the consistency CDI brings to developer experience.</p>
</div>
<div class="paragraph">
<p>Yet, CDI was designed more than 10 years ago at a time when monolithic applications were deployed as ears and wars sharing a highly dynamic yet monolithic application server. Things have changed, where containers are immutable, obviating the need for hot redeploy and dynamic discovery, and aspects that we used to rely on traditional application servers for, such as availability and redundancy are now handled using cloud orchestration with kubernetes. We also have seen a shift from monolithic apps to a greater emphasis on decoupling and resilience through microservices. These factors have given rise to the “single app stack”, where the framework and the application are fused as one. With traditional application servers, applications had to be dynamic <strong>because</strong> they needed to differentiate their needs on shared application server infrastructure, where configuration and resources applied equally to all applications. With single application stacks, applications can express their needs more statically because they are scoped to a single application.</p>
</div>
<div class="paragraph">
<p>In addition, today’s deployments require increasing efficiency to achieve cost reduction, whether deploying to cloud providers or in-house virtualized data centers. A single application server instance is often replaced by a dozen microservice “single-app stack” instances, with double or triple that amount to achieve redundancy. CDI, as it is today, is not suited for this cloud ready approach. Some of its features imply a rather heavy resource consumption (both boot-time and memory usage) in its implementations.<br>
This blog post covers some of my CDI vision for the future to make the specification relevant for the next 10 years.</br>
</p>
<div class="sect1">
<h2 id="how-to-make-cdi-cloud-ready"><a class="anchor" href="#how-to-make-cdi-cloud-ready" />How to make CDI cloud ready?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>If we want to make CDI a cloud ready specification we have to look into all of its requirements that impact memory, cpu, and more broadly performance. As part of that we should revisit which capabilities and features are still required, since as mentioned above application architecture and deployment environments have changed significantly over the years. Although, that alone is not enough, we need to ensure CDI is flexible and adaptable enough to allow for innovative implementation approaches, such as build-time injection wiring.</p>
</div>
<div class="paragraph">
<p>Of course, It should be possible to implement runtime-based approaches in a more efficient manner, and in many ways these goals are complimentary. One example of this is overly aggressive bean discovery and thus the extensive type scanning required by CDI during initialization. While bean discovery allows seamless integration in that 3rd party non-CDI classes can be discovered as bean, storing state and generating events on classes which were never intended to be a bean is very costly. That’s the reason why, when we introduced CDI for Java SE in CDI 2.0, we provided a way to disable <a href="https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#se_container_initializer">bean discovery</a> and let the developers explicitly declare classes that should become beans or allow the creation of synthetic beans before launching the container.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="eclipse-microprofile-challenges"><a class="anchor" href="#eclipse-microprofile-challenges" />Eclipse MicroProfile Challenges</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The CDI spec was originally written with Jakarta EE integration in mind, and as such, it assumes the full platform is available and thus the spec and the TCKs require JSF, EL, and EJB. This is not the best fit for MicroProfile, since it targets microservice usage patterns. Under MicroProfile not even Servlet is required, let alone EJB, EL, and JSF. Likewise, MicroProfile can’t be based on CDI SE, since SE does not include JAX-RS integration, which is essential for REST based microservices.</p>
</div>
<div class="paragraph">
<p>To solve this problem, the MicroProfile specifications effectively depend on a subset of the CDI spec, explicitly noting the above API elements are to be excluded. This is awkward and has led to confusion about how one achieves compliance.</p>
</div>
<div class="paragraph">
<p>Ultimately, the problem is that the CDI spec couples too many elements together. We need greater flexibility to allow for as many different platforms and environments to adopt and build off the standard.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="introducing-cdi-lite"><a class="anchor" href="#introducing-cdi-lite" />Introducing CDI Lite</h2>
<div class="sectionbody">
<div class="paragraph">
<p>If you followed the CDI 2.0 expert group work a few years back, this title should ring a bell. CDI Lite was in the air back then, since we did expect some future need of added flexibility, but due to a lack of time and clear target we postponed its addition to the spec.</p>
</div>
<div class="paragraph">
<p>With the CDI programming model being core to MicroProfile, it seems obvious that its use cases should be considered as a first-class usage of CDI. Further, we should enable CDI composition into any other platform, such as future Jakarta EE profiles, or combining it with other frameworks on top of plain old Java as a contribution to future innovations within the Java ecosystem.</p>
</div>
<div class="paragraph">
<p>So what should CDI Lite’s goal be? In my opinion we should define it as: “the core subset of CDI features that enables the greatest number of CDI implementations, CDI usage within the Java ecosystem, and opens the door to innovation, notably build-time injection approaches.”</p>
</div>
<div class="paragraph">
<p>Not only would this improve the existing CDI ecosystem, it opens the door to many other interesting use cases such as:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><strong>Transcompilation.</strong> It becomes possible to compile Java based injection into other language environments, such as Javascript. This is currently possible with Dagger and Kodein for Kotlin but not CDI</p>
</li>
<li>
<p><strong>Mobile platform support.</strong> By enabling build time injection, it also becomes possible for an implementer to target mobile platforms such as Android.</p>
</li>
<li>
<p><strong>Native Compilation.</strong> By enabling build-time Java, the door is also opened to generating optimal native compiled images utilizing static compilers such as the GraalVM project.</p>
</li>
</ul>
</div>
<div class="sect2">
<h3 id="how-to-add-cdi-lite-to-the-spec"><a class="anchor" href="#how-to-add-cdi-lite-to-the-spec" />How to add CDI lite to the spec?</h3>
<div class="paragraph">
<p>Today, thanks to CDI 2.0 work, the spec is split into 3 parts: core, CDI for SE and CDI for EE.</p>
</div>
<div class="imageblock">
<div class="content">
<img src="http://www.cdi-spec.org/images/cdi2-layers.png" alt="cdi2 layers">
</img>
<div class="title">Figure 1. Current CDI spec layering</div>
</div>
<div class="paragraph">
<p>Users and implementers are already familiar with the notion of different “flavors” for CDI. Adding CDI Lite implies some work but the spec is already well organized to support such a change. Roughly, CDI lite should be defined as the core subset of which core, EE and SE extend. Further the EE spec integrations themselves can be defined in such a way so that each framework’s integration is optional, allowing any combination such as a standalone JAX-RS implementation with CDI support. Additionally this would enable future additional Jakarta EE profiles beyond just web and full.<br>
This evolution would split Core CDI in CDI Lite and “Heavy CDI” as shown below. The CDI lite part could benefit CDI for Se as other platforms like MicroProfile.</br>
</p>
<div class="imageblock">
<div class="content">
<img src="http://www.cdi-spec.org/images/cdi3-layers.png" alt="cdi3 layers">
</img>
<div class="title">Figure 2. Spliting CDI Core in <em>lite</em> and <em>full</em></div>
</div>
</div>
<div class="sect2">
<h3 id="cdi-lite-scope"><a class="anchor" href="#cdi-lite-scope" />CDI Lite Scope</h3>
<div class="paragraph">
<p>The essential fundamental core of CDI is the programming model exposed to users which enables uniform annotation driven injection and further supports contextual state driven injection. Just the annotations defined in JSR-330 are not enough, there is also the need for a number of other common patterns and usages to make the framework complete.</p>
</div>
<div class="paragraph">
<p>Support popular CDI features like:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Beans (class, producers and synthetic beans)</p>
</li>
<li>
<p>CDI DI (typesafe resolution, qualifiers, dynamic lookup)</p>
</li>
<li>
<p>Most built-in scopes (singleton, application, request, and dependent)</p>
</li>
<li>
<p>Contextual instances and their lifecycle</p>
</li>
<li>
<p>Interceptors</p>
</li>
<li>
<p>Events</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Other features may be added but may not have reached broad adoption like decorators, transactional events or specialization, so additional discussion would be needed.. Ideally we would utilize the opportunity to reduce technical debt, since each increases code complexity, and some of these underused capabilities are a major source of bug reports:</p>
</div>
<div class="olist arabic">
<ol class="arabic">
<li>
<p>Decorators have 67 issues in the RI alone</p>
</li>
<li>
<p>Specialization has 28 RI issues and 6 open spec issues</p>
</li>
</ol>
</div>
</div>
<div class="sect2">
<h3 id="outside-cdi-lite-scope"><a class="anchor" href="#outside-cdi-lite-scope" />Outside CDI Lite Scope</h3>
<div class="paragraph">
<p>A number of features are only relevant to particular framework integrations. For example SessionScope is only relevant if the runtime environment implements Servlet (HttpSession), and ConversationScope is incomplete without EL and JSF. These technologies are not needed in a microservice scenario, as is the case in MicroProfile, and so should not be required.</p>
</div>
<div class="paragraph">
<p>Another capability that should be excluded from CDI Lite is portable extensions, but still part of CDI Full. Portable extensions run in opposition to the goals described above, since they are inherently a runtime-only contract which mandates a very specific container initialization lifecycle. As an example, portable extensions are often stateful, but they are not serializable, and any state they have can be passed into other beans or as part of lifecycle events that are required to occur. Further they are allowed to manipulate almost anything pertaining to a bean at just about every phase of the CDI lifecycle. These factors effectively preclude any implementation that aims to pregenerate wiring at build time. Yet extension implementations rarely need such an open-ended do-anything-you-want API.</p>
</div>
<div class="paragraph">
<p>Instead, the CDI-Lite could address these concerns through purpose-built SPIs, such as introducing a new explicit way to register annotated types and beans. It’s already partly done in CDI for SE in which users can programmatically add synthetic beans without portable extensions.</p>
</div>
<div class="paragraph">
<p>All of the elements outside of the CDI-Lite scope would still be a part of the full specification, as the intention is not to affect existing implementations, only to open the door to new approaches and new implementations.</p>
</div>
<div class="paragraph">
<p>In the end, we would end up with a much more flexible standard that benefits everyone and carries over the same powerful programming model to new use-cases while bringing improved efficiency to modern cloud deployment scenarios. <br>
CDI Llite introduction wouldn’t be the pretext to deprecate existing features but to make the framework more modular and ready for all todays use cases and make it ready for future evolution.</br>
</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="conclusion"><a class="anchor" href="#conclusion" />Conclusion</h2>
<div class="sectionbody">
<div class="paragraph">
<p>As you may guess this spec evolution idea will require a lot of analysis and discussion. Should the Jakarta Contexts and Dependency Injection Project agree to go this way, we could imagine starting work on this new CDI version, but as usual, feedback from the community is very important to us. So feel free to share your thoughts in the comments of this post.</p>
</div>
<div class="paragraph">
<p>Thanks for helping us keep the CDI programming model around for the next 10 years!</p>
</div>
</div>
</div></div></div></div></div></div></div>
http://www.cdi-spec.org/news/2017/05/15/CDI_2_is_released.htmlCDI 2.0 is released2020-09-18T08:53:43+02:002017-05-15T00:00:00+00:00
Our JCP Expert Group is pleased to announce the release of Contexts and Dependency Injection for Java 2.0.
Specification, reference implementation (JBoss Weld 3.0.0.Final) and TCK can be downloaded here.
What is CDI?
CDI is one of the major Java EE specification.
It was introduced with Java EE 6 in 2009, updated for Java EE 7 and now with version 2.0 it is ready for Java EE 8 as well for Java SE or other platform like Micropofile.
CDI defines a powerful set of complementary services that help improve the structure of application code.
A well-defined lifecycle for stateful objects bound to lifecycle contexts, where the...
<div class="paragraph">
<p>Our <a href="https://www.jcp.org/en/jsr/detail?id=365" target="_blank">JCP Expert Group</a> is pleased to announce the release of Contexts and Dependency Injection for Java 2.0.</p>
</div>
<div class="paragraph">
<p>Specification, reference implementation (<strong>JBoss Weld 3.0.0.Final</strong>) and TCK can be downloaded <a href="http://www.cdi-spec.org/download/" target="_blank">here</a>.</p>
</div>
<div class="sect1">
<h2 id="what-is-cdi"><a class="anchor" href="#what-is-cdi" />What is CDI?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>CDI is one of the major Java EE specification.</p>
</div>
<div class="paragraph">
<p>It was introduced with Java EE 6 in 2009, updated for Java EE 7 and now with version 2.0 it is ready for Java EE 8 as well for Java SE or other platform like <a href="http://microprofile.io" target="_blank">Micropofile</a>.</p>
</div>
<div class="paragraph">
<p>CDI defines a powerful set of complementary services that help improve the structure of application code.</p>
</div>
<div class="ulist">
<ul>
<li>
<p>A well-defined lifecycle for stateful objects bound to lifecycle contexts, where the set of contexts is extensible</p>
</li>
<li>
<p>A sophisticated, typesafe dependency injection mechanism, including the ability to select dependencies at either development or deployment time, without verbose configuration</p>
</li>
<li>
<p>Support for Java EE modularity and the Java EE component architecture?the modular structure of a Java EE application is taken into account when resolving dependencies between Java EE components</p>
</li>
<li>
<p>Integration with the Unified Expression Language (EL), allowing any contextual object to be used directly within a JSF or JSP page</p>
</li>
<li>
<p>The ability to decorate injected objects</p>
</li>
<li>
<p>The ability to associate interceptors to objects via typesafe interceptor bindings</p>
</li>
<li>
<p>An event notification model</p>
</li>
<li>
<p>A web conversation context in addition to the three standard web contexts defined by the Java Servlets specification</p>
</li>
<li>
<p>An SPI allowing portable extensions to integrate cleanly with the container</p>
</li>
</ul>
</div>
</div>
</div>
<div class="sect1">
<h2 id="major-features-included-in-cdi-2-0"><a class="anchor" href="#major-features-included-in-cdi-2-0" />Major features included in CDI 2.0</h2>
<div class="sectionbody">
<div class="paragraph">
<p>This CDI 2.0 includes important changes for the platform.</p>
</div>
<div class="ulist">
<ul>
<li>
<p>The spec was split into <a href="http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#doc_organisation">3 parts</a> to add the support for Java SE.</p>
</li>
<li>
<p>API to <a href="http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#se_bootstrap">boot CDI in Java SE</a>.</p>
</li>
<li>
<p>Observers (i.e. events) <a href="http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observer_ordering">ordering</a>.</p>
</li>
<li>
<p><a href="http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#firing_events_asynchronously">Asynchronous event</a>.</p>
</li>
<li>
<p><a href="http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#configurators">Configurators</a> for major SPI elements</p>
</li>
<li>
<p>Possibility to <a href="http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#process_observer_method">configure or veto observer methods</a>.</p>
</li>
<li>
<p>Add <a href="http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#built_in_annotation_literals">built-in annotation literals</a></p>
</li>
<li>
<p>Make possible to <a href="http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#interception_factory">apply interceptor on producers</a>.</p>
</li>
<li>
<p>Alignment on Java 8 features (streams, lambdas, repeating qualifiers)</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>A lot of other small feature will be delivered. Refer to the coming release notes to check them all.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="start-using-cdi-2-0-today-with-weld-3-0"><a class="anchor" href="#start-using-cdi-2-0-today-with-weld-3-0" />Start using CDI 2.0 today with Weld 3.0</h2>
<div class="sectionbody">
<div class="paragraph">
<p>To develop your CDI 2.0 code just add cdi-api 2.0 your pom.xml.</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-xml" data-lang="xml"><dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<version>2.0</version>
</dependency></code></pre>
</div>
</div>
<div class="paragraph">
<p>You can then run your code on Java SE or on WildFly </p>
</div>
<div class="sect2">
<h3 id="running-on-java-se-with-weld-se"><a class="anchor" href="#running-on-java-se-with-weld-se" />Running on Java SE with Weld SE</h3>
<div class="paragraph">
<p>You can then run your code on Java SE thanks to Weld SE, just add this dependency to your project:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-xml" data-lang="xml"><dependency>
<groupId>org.jboss.weld.se</groupId>
<artifactId>weld-se-shaded</artifactId>
<version>3.0.0.Final</version>
</dependency></code></pre>
</div>
</div>
<div class="paragraph">
<p>You can then, bootstrap the CDI container in your code like this</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">public static void main(String... args) {
try(SeContainer container = SeContainerInitializer.newInstance().initialize()) {
// start the container, retrieve a bean and do work with it
MyBean myBean = container.select(MyBean.class).get();
myBean.doWork();
}
// shuts down automatically after the try with resources block.
}</code></pre>
</div>
</div>
</div>
<div class="sect2">
<h3 id="running-on-java-ee-by-patching-wildfly"><a class="anchor" href="#running-on-java-ee-by-patching-wildfly" />Running on Java EE by patching WildFly</h3>
<div class="paragraph">
<p>We also provide a <a href="http://download.jboss.org/weld/3.0.0.Final/">patch for WildFly 10.1.0</a> to update Weld and thus CDI version on JBoss WildFly.</p>
</div>
<div class="paragraph">
<p>To do so just download and unzip <a href="http://wildfly.org/downloads/">WildFly 10.1.0.Final</a>, then download the patch (don’t unzip it), go to the <code><WILDFLY_HOME>/bin</code> directory and patch the server with the following command:</p>
</div>
<div class="paragraph">
<p><code>./jboss-cli.sh --command="patch apply <PATH_TO_PATCH>/wildfly-10.1.0.Final-weld-3.0.0.Final-patch.zip"</code></p>
</div>
<div class="paragraph">
<p>you should obtain the following result in the console:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-json" data-lang="json">{
"outcome" : "success",
"result" : {}
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>Your WildFly server is now patched to use CDI 2.0 and Weld 3.0.0.Final.</p>
</div>
<div class="paragraph">
<p>GlassFish 5.0 with CDI 2.0 support should be release in the coming weeks.</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="stay-tuned"><a class="anchor" href="#stay-tuned" />Stay tuned</h2>
<div class="sectionbody">
<div class="paragraph">
<p>We’ll provide more article on CDI 2.0 new features so stay tuned by following <a href="https://twitter.com/cdispec">@cdispec</a> twitter account.</p>
</div>
</div>
</div>
http://www.cdi-spec.org/news/2017/02/01/CDI_2_is_in_public_review.htmlCDI 2.0 is in public review2020-09-18T08:53:43+02:002017-02-01T00:00:00+00:00
CDI 2.0 is now in public review status, you can now grab the PRD of the spec ot download the Javadoc.
Major features included in CDI 2.0
This CDI 2.0 includes important changes for the platform.
The spec was split into 3 parts to add the support for Java SE.
API to boot CDI in Java SE.
Observers (i.e. events) ordering.
Asynchronous event.
Configurators for major SPI elements
Possibility to configure or veto observer methods.
Add built-in annotation literals
Make possible to apply interceptor on producers.
Alignment on Java 8 features (streams, lambdas, repeating qualifiers)
A lot of other small feature will be delivered. Refer to the coming release notes to check...
<div class="paragraph">
<p>CDI 2.0 is now in public review status, you can now grab the <a href="https://jcp.org/aboutJava/communityprocess/pr/jsr365/index.html" target="_blank">PRD of the spec</a> ot download the <a href="https://jcp.org/aboutJava/communityprocess/pr/jsr365/index.html" target="_blank">Javadoc</a>.</p>
</div>
<div class="sect1">
<h2 id="major-features-included-in-cdi-2-0"><a class="anchor" href="#major-features-included-in-cdi-2-0" />Major features included in CDI 2.0</h2>
<div class="sectionbody">
<div class="paragraph">
<p>This CDI 2.0 includes important changes for the platform.</p>
</div>
<div class="ulist">
<ul>
<li>
<p>The spec was split into <a href="http://docs.jboss.org/cdi/spec/2.0-PRD/cdi-spec.html#doc_organisation" target="_blank">3 parts</a> to add the support for Java SE.</p>
</li>
<li>
<p>API to <a href="http://docs.jboss.org/cdi/spec/2.0-PRD/cdi-spec.html#se_bootstrap" target="_blank">boot CDI in Java SE</a>.</p>
</li>
<li>
<p>Observers (i.e. events) <a href="http://docs.jboss.org/cdi/spec/2.0-PRD/cdi-spec.html#observer_ordering" target="_blank">ordering</a>.</p>
</li>
<li>
<p><a href="http://docs.jboss.org/cdi/spec/2.0-PRD/cdi-spec.html#firing_events_asynchronously" target="_blank">Asynchronous event</a>.</p>
</li>
<li>
<p><a href="http://docs.jboss.org/cdi/spec/2.0-PRD/cdi-spec.html#configurators" target="_blank">Configurators</a> for major SPI elements</p>
</li>
<li>
<p>Possibility to <a href="http://docs.jboss.org/cdi/spec/2.0-PRD/cdi-spec.html#process_observer_method" target="_blank">configure or veto observer methods</a>.</p>
</li>
<li>
<p>Add <a href="http://docs.jboss.org/cdi/spec/2.0-PRD/cdi-spec.html#built_in_annotation_literals" target="_blank">built-in annotation literals</a></p>
</li>
<li>
<p>Make possible to <a href="http://docs.jboss.org/cdi/spec/2.0-PRD/cdi-spec.html#interception_factory" target="_blank">apply interceptor on producers</a>.</p>
</li>
<li>
<p>Alignment on Java 8 features (streams, lambdas, repeating qualifiers)</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>A lot of other small feature will be delivered. Refer to the coming release notes to check them all.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="ri-is-also-available"><a class="anchor" href="#ri-is-also-available" />RI is also available</h2>
<div class="sectionbody">
<div class="paragraph">
<p>We also provide a pre-release for the RI and API, thus You can start testing CDI 2.0 with Weld 3.0 CR1 that you can download <a href="http://download.jboss.org/weld/3.0.0.CR1/" target="_blank">here</a>.</p>
</div>
<div class="paragraph">
<p>To develop your CDI 2.0 code just switch cdi-api in your pom.xml to this version:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="nowrap"><dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<version>2.0-PFD</version>
</dependency></pre>
</div>
</div>
<div class="paragraph">
<p>We also provide a <a href="http://download.jboss.org/weld/3.0.0.CR1/" target="_blank">patch for WildFly 10.1.0</a> to help users evaluate CDI 2.0 under a Java EE application server.</p>
</div>
<div class="paragraph">
<p>To do so just download and unzip <a href="http://wildfly.org/downloads/" target="_blank">WildFly 10.1.0.Final</a>, then download the patch (no need to unzip it), go to the <code><WILDFLY_HOME>/bin</code> directory and patch the server with the following command:</p>
</div>
<div class="paragraph">
<p><code>./jboss-cli.sh --command="patch apply <PATH_TO_PATCH>/wildfly-10.1.0.Final-weld-3.0.0.CR1-patch.zip"</code></p>
</div>
<div class="paragraph">
<p>you should obtain the following result in the console:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="nowrap">{
"outcome" : "success",
"result" : {}
}</pre>
</div>
</div>
<div class="paragraph">
<p>Your WildFly server is now patched to use CDI 2.0 and Weld 3.0 CR1.</p>
</div>
<div class="paragraph">
<p>Happy testing!</p>
</div>
</div>
</div>
http://www.cdi-spec.org/news/2017/01/05/CDI_2_Beta_1_is_available.htmlCDI 2.0 Beta 1 is available2020-09-18T08:53:43+02:002017-01-05T00:00:00+00:00
After more than 2 years of work CDI 2.0 is around the corner. Its feature list is now complete and Beta for RI (Weld 3.0 Beta1) is available for download.
This post lists what’s included and give you some insight on the final release and what comes next
Give it a try
First, you may want to start testing the RI and discover the new API, all the resources are listed below:
You can browse the spec document in html or pdf
If you prefer Javadoc you can read it here
CDI 2.0 Beta API is available on Maven Central. You can also download the jar...
<div class="paragraph">
<p>After more than 2 years of work CDI 2.0 is around the corner. Its feature list is now complete and Beta for RI (Weld 3.0 Beta1) is available for download.
This post lists what’s included and give you some insight on the final release and what comes next</p>
</div>
<div class="sect1">
<h2 id="give-it-a-try"><a class="anchor" href="#give-it-a-try" />Give it a try</h2>
<div class="sectionbody">
<div class="paragraph">
<p>First, you may want to start testing the RI and discover the new API, all the resources are listed below:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>You can browse the spec document in <a href="http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html" target="_blank">html</a> or <a href="http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.pdf">pdf</a></p>
</li>
<li>
<p>If you prefer Javadoc you can read it <a href="http://docs.jboss.org/cdi/api/2.0.Beta1">here</a></p>
</li>
<li>
<p>CDI 2.0 Beta API is available on <a href="http://search.maven.org/#artifactdetails|javax.enterprise|cdi-api|2.0.Beta1|jar" target="_blank">Maven Central</a>. You can also download the jar <a href="http://search.maven.org/remotecontent?filepath=javax/enterprise/cdi-api/2.0.Beta1/cdi-api-2.0.Beta1.jar">here</a></p>
</li>
<li>
<p>Last but not least, the reference implementation (Weld 3.0 Beta 1) is downloadable <a href="http://download.jboss.org/weld/3.0.0.Beta1/" target="_blank">here</a> and can be also be used from <a href="http://search.maven.org/#artifactdetails|org.jboss.weld|weld-core-impl|3.0.0.Beta1|jar" target="_blank">Maven</a></p>
</li>
</ul>
</div>
</div>
</div>
<div class="sect1">
<h2 id="major-features-included-in-cdi-2-0"><a class="anchor" href="#major-features-included-in-cdi-2-0" />Major features included in CDI 2.0</h2>
<div class="sectionbody">
<div class="paragraph">
<p>This CDI 2.0 includes important changes for the platform.</p>
</div>
<div class="ulist">
<ul>
<li>
<p>The spec was split into <a href="http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#doc_organisation" target="_blank">3 parts</a> to add the support for Java SE.</p>
</li>
<li>
<p>API to <a href="http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#se_bootstrap" target="_blank">boot CDI in Java SE</a>.</p>
</li>
<li>
<p>Observers (i.e. events) <a href="http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#observer_ordering" target="_blank">ordering</a>.</p>
</li>
<li>
<p><a href="http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#firing_events_asynchronously" target="_blank">Asynchronous event</a>.</p>
</li>
<li>
<p><a href="http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#configurators" target="_blank">Configurators</a> for major SPI elements</p>
</li>
<li>
<p>Possibility to <a href="http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#process_observer_method" target="_blank">configure or veto observer methods</a>.</p>
</li>
<li>
<p>Add <a href="http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#built_in_annotation_literals" target="_blank">built-in annotation literals</a></p>
</li>
<li>
<p>Make possible to <a href="http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#interception_factory" target="_blank">apply interceptor on producers</a>.</p>
</li>
<li>
<p>Alignment on Java 8 features (streams, lambdas, repeating qualifiers)</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>A lot of other small feature will be delivered. Refer to the coming release notes to check them all.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="release-agenda"><a class="anchor" href="#release-agenda" />Release agenda</h2>
<div class="sectionbody">
<div class="paragraph">
<p>If everything stays on track we should send the PFD (proposed final draft) with TCK and RI to the JCP soon.</p>
</div>
<div class="paragraph">
<p>If the JCP ballot is green, CDI 2.0 final could be released before end of February.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="what-s-next"><a class="anchor" href="#what-s-next" />What’s next</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Our release plan for CDI 2.0 has always been to deliver it before Java EE 8 to let other spec grab our new features and make the best out of them.</p>
</div>
<div class="paragraph">
<p>We are still considering to start working on CDI 2.1 to clarify or add the few features needed for Java EE 8 and beyond.</p>
</div>
<div class="paragraph">
<p>Stay tuned.</p>
</div>
</div>
</div>
http://www.cdi-spec.org/news/2015/10/23/Meet-CDI-at-java-one-2015.htmlMeet CDI at Java One 20152020-09-18T08:53:43+02:002015-10-23T00:00:00+00:00
During Java One 2015, a lot of CDI related talks and event will happen. find most of them in this post
CDI related talks
In this agenda you’ll find most of CDI related talk to help you prepare your schedule
Focus on EG talks
If you want to have the best of CDI overview in Java One, don’t miss these talks:
CDI 2.0: Whats in the Works? (monday 12:30, Cyril Magnin I): to learn about coming features in CDI 2.0
Apache DeltaSpike, the CDI Toolbox (monday 2:30, Cyril Magnin I): Discover Apache DeltaSpike, the heart of CDI Ecosystem
Advanced CDI in live coding (tuesday 8:30, Cyril Magnin...
<div class="paragraph">
<p>During Java One 2015, a lot of CDI related talks and event will happen. find most of them in this post</p>
</div>
<div class="sect1">
<h2 id="cdi-related-talks"><a class="anchor" href="#cdi-related-talks" />CDI related talks</h2>
<div class="sectionbody">
<div class="paragraph">
<p>In this agenda you’ll find most of CDI related talk to help you prepare your schedule</p>
</div>
<iframe src="https://calendar.google.com/calendar/embed?title=CDI%20Talks%20in%20Java%20One%202015&showNav=0&showDate=0&showPrint=0&showCalendars=0&mode=AGENDA&height=600&wkst=1&hl=en&bgcolor=%23FFFFFF&src=sabot-durand.net_uq9ukhrb7o6mi5g6t3dlbbd8sc%40group.calendar.google.com&color=%231B887A&ctz=America%2FLos_Angeles&dates=20151025%2F20151030" style="border-width:0" width="800" height="700" frameborder="0" scrolling="no" />
</div>
</div>
<div class="sect1">
<h2 id="focus-on-eg-talks"><a class="anchor" href="#focus-on-eg-talks" />Focus on EG talks</h2>
<div class="sectionbody">
<div class="paragraph">
<p>If you want to have the best of CDI overview in Java One, don’t miss these talks:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><strong>CDI 2.0: Whats in the Works?</strong> (monday 12:30, Cyril Magnin I): to learn about coming features in CDI 2.0</p>
</li>
<li>
<p><strong>Apache DeltaSpike, the CDI Toolbox</strong> (monday 2:30, Cyril Magnin I): Discover Apache DeltaSpike, the heart of CDI Ecosystem</p>
</li>
<li>
<p><strong>Advanced CDI in live coding</strong> (tuesday 8:30, Cyril Magnin II/II): learn the power of CDI portable extension to integrate your framework in CDI programming model</p>
</li>
</ul>
</div>
</div>
</div>
<div class="sect1">
<h2 id="i-ll-be-available-for-you-questions"><a class="anchor" href="#i-ll-be-available-for-you-questions" />I’ll be available for you questions</h2>
<div class="sectionbody">
<div class="paragraph">
<p>You’ll find me at the Hackergarten Tuesday afternoon and wednesday morning to help you on CDI, answer your question or discuss the spec.
You can even pass by just to say Hello aor bring me a <span class="line-through">beer</span>, coffee ;).</p>
</div>
<div class="paragraph">
<p>Have a nice Java One Week.</p>
</div>
</div>
</div>
http://www.cdi-spec.org/news/2015/10/15/Learn-CDI-with-TCK.htmlLearn CDI spec with our TCK2020-09-18T08:53:43+02:002015-10-15T00:00:00+00:00
Beyond being one of the few open source TCK around, CDI TCK is one of the easiest to get started with.
Now that we have released a new version of spec doc embedding TCK test, it’s easier than ever.
Learn what we did and how to use it.
CDI TCK for the dummies
TCK stands for Technology Compatibility Kit.
It’s one of the 3 part a JSR expert group has to release (2 others being the spec and the Reference Implementation).
A TCK is a collection of tests that actively define the spec.
It’s the tool that is used to determine if an implementation is a CDI...
<div class="paragraph">
<p>Beyond being one of the few open source TCK around, CDI TCK is one of the easiest to get started with.</p>
</div>
<div class="paragraph">
<p>Now that we have released a new version of spec doc embedding TCK test, it’s easier than ever.</p>
</div>
<div class="paragraph">
<p>Learn what we did and how to use it.</p>
</div>
<div class="sect1">
<h2 id="cdi-tck-for-the-dummies"><a class="anchor" href="#cdi-tck-for-the-dummies" />CDI TCK for the dummies</h2>
<div class="sectionbody">
<div class="paragraph">
<p>TCK stands for Technology Compatibility Kit.
It’s one of the 3 part a JSR expert group has to release (2 others being the spec and the Reference Implementation).</p>
</div>
<div class="paragraph">
<p>A TCK is a collection of tests that actively define the spec.
It’s the tool that is used to determine if an implementation is a CDI implementation or not.
So this piece of code is the most important and the hardest to develop and maintain.
Ok, RI could seem more important, but it’s under the spotlight and is nothing without the TCK.</p>
</div>
<div class="paragraph">
<p>To make short, TCK is the code that makes CDI a specification and thus a standard.</p>
</div>
<div class="paragraph">
<p>The great guy behind our TCK is <a href="https://github.com/tremes" target="_blank"><strong>Tomas Remes</strong></a> and he doing an awesome job pointing holes or unclear statements in spec text or refactoring all the TCK after CDI split in 2.0-EDR1.</p>
</div>
<div class="paragraph">
<p>If you want to learn more about the TCK I suggest that you check <a href="http://www.cdi-spec.org/cditck" target="_blank">our dedicated page</a>.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="tck-is-more-than-what-it-seems"><a class="anchor" href="#tck-is-more-than-what-it-seems" />TCK is more than what it seems</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The TCK role is not restricted to the specification mold, it can also be a great way to learn the spec by code.
To crown that, thanks to <a href="http://arquillian.org" target="_blank">Arquillian</a>, CDI TCK is very easy to understand and very expressive.</p>
</div>
<div class="paragraph">
<p>But jumping from specification to test can be a bit complicated and this exercise can discourage many of our user.</p>
</div>
<div class="paragraph">
<p>That’s why, a few months ago, we started to think about a solution to create links from the spec text to the TCK.</p>
</div>
<div class="paragraph">
<p>It seemed quite doable since the reverse link has always existed: each since TCK tests have meta data about the spec section it refers.</p>
</div>
<div class="paragraph">
<p>So, Tomas made the required upgrade to the TCK and developed a script to add tests to the spec.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="meet-spec-doc-with-tck-assertion"><a class="anchor" href="#meet-spec-doc-with-tck-assertion" />Meet Spec doc with TCK assertion</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Thanks to this work we are able to release a <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec-with-assertions.html" target="_blank">special edition of CDI 1.2 specification document including TCK assertion and link to their matching test class on Github</a>.
The same is done for the <a href="http://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec-with-assertions.html">CDI 2.0 work in progress specification</a>.</p>
</div>
<div class="paragraph">
<p>Don’t worry the original specifications docs stay unchanged, we only released a new flavor for them on our <a href="http://www.cdi-spec.org/download">download page</a>.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="assertion-link-by-example"><a class="anchor" href="#assertion-link-by-example" />Assertion link by example</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Due to normalization constraint (rules duplication avoidance) we have on the spec, some statement could seem confusing when reading them.</p>
</div>
<div class="paragraph">
<p>Let’s take, for instance, the first statement of section <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec-with-assertions.html#unproxyable" target="_blank">3.15 Unproxyable bean types</a>:</p>
</div>
<div class="quoteblock">
<blockquote>
<div class="paragraph">
<p>The container uses proxies to provide certain functionality. Certain legal bean types cannot be proxied by the container:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>classes which don’t have a non-private constructor with no parameters,</p>
</li>
</ul>
</div>
</blockquote>
</div>
<div class="paragraph">
<p>Yeah a triple negation…</p>
</div>
<div class="paragraph">
<p>You could take the next minute to figure out the exact meaning of the sentence or you could click on the "Show TCK assertions" link and check the two tests related to this section to see the cases where this rules make the deployment fails.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="learn-test-and-challenge"><a class="anchor" href="#learn-test-and-challenge" />Learn, test and challenge</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Now that you have this nice tool in your hand, TCK will be your CDI Lab, and perhaps, you’ll come back with corner use cases not covered or new challenges for the TCK.</p>
</div>
<div class="paragraph">
<p>Go and learn!</p>
</div>
</div>
</div>
http://www.cdi-spec.org/news/2015/09/29/Second-F2F-meeting.htmlCDI 2.0 Second Face to face meeting feedback2020-09-18T08:53:43+02:002015-09-29T00:00:00+00:00
Last week we had our second CDI 2.0 Face to Face meeting in Paris (France).
This is a summary of the point discussed and leads we’d like to follow.
Of course each point we’ll lead to a proposal later and discussed on the mailing list.
Roadmap
CDI 2.0 is still planned for 1st half 2016.
We’ll focus on new feature and SE support for this release.
CDI 2.1 should start after 2.0 release and focus Java EE 8 specific enhancement.
We’ll probably focus a bit more on modularity since Java 9 will be around the corner giving us a better visibility of how anticipate its new module...
<div class="paragraph">
<p>Last week we had our second CDI 2.0 Face to Face meeting in Paris (France).
This is a summary of the point discussed and leads we’d like to follow.
Of course each point we’ll lead to a proposal later and discussed on the mailing list.</p>
</div>
<div class="sect1">
<h2 id="roadmap"><a class="anchor" href="#roadmap" />Roadmap</h2>
<div class="sectionbody">
<div class="paragraph">
<p>CDI 2.0 is still planned for 1st half 2016.
We’ll focus on new feature and SE support for this release.</p>
</div>
<div class="paragraph">
<p>CDI 2.1 should start after 2.0 release and focus Java EE 8 specific enhancement.
We’ll probably focus a bit more on modularity since Java 9 will be around the corner giving us a better visibility of how anticipate its new module approach.
Content of 2.1 will be defined in the coming weeks</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="cdi-se-review"><a class="anchor" href="#cdi-se-review" />CDI SE review</h2>
<div class="sectionbody">
<div class="paragraph">
<p>CDI bootstrap on Java SE is one of the feature released in our first early draft.
The Java SE support needed extra work to be complete and we wanted to review the boot api included to see how it could be enhanced.</p>
</div>
<div class="sect2">
<h3 id="bootstrap-api"><a class="anchor" href="#bootstrap-api" />bootstrap API</h3>
<div class="paragraph">
<p>We’d like to review the proposed bootstrap API to make it a bit richer and have the boot process in a specific class.
The idea is to get inspiration from the new Weld Se bootstrap with a builder pattern (see <a href="https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/Weld.java"><code>Weld</code></a> and <a href="https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldContainer.java"><code>WeldContainer</code></a> classes) and the possibility to explicitly choose the implementation if multiple impl should be in classpath.</p>
</div>
</div>
<div class="sect2">
<h3 id="context-control"><a class="anchor" href="#context-control" />Context control</h3>
<div class="paragraph">
<p>This feature seemed a bit risky to specify. We’d preferred an approach based on existing built-in scope: RequestScoped and an interceptor activating it for a given invocation and unactivating it just after . something like this:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">@WithinRequest
public void doSomethigWithRequestScopedBeans() {
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>This could give users the possibility to start and stop a context without explicitly adding these methods in the SPI
We also discussed the possibility to have a Conversation-like context activated thru a built-in scope.</p>
</div>
</div>
<div class="sect2">
<h3 id="bean-discovery-mode"><a class="anchor" href="#bean-discovery-mode" />Bean discovery mode</h3>
<div class="paragraph">
<p>The new bootstrap api should prevent us to specify a new bean discovery mode since the builder api will contains a mean to deactivate bean discovery and create a synthetic bean archive by adding class and packages of beans.</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="async-event-review"><a class="anchor" href="#async-event-review" />Async event review</h2>
<div class="sectionbody">
<div class="paragraph">
<p>There was discussion about exceptions handling and the issues raised from mixing sync and async observers. So the leads we’d like to follow are the following</p>
</div>
<div class="ulist">
<ul>
<li>
<p>stop calling sync observer from fireAsync() (fire() is for @Observes and fireAsync() is for @ObservesAsync)</p>
</li>
<li>
<p>Remove <code>FireAsyncException</code> in favor of <code>CompletionException</code> since an exception during async events pipeline execution is noting more than that.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>To sum it up:</p>
</div>
<table class="tableblock frame-all grid-all" style="width: 70%;">
<caption class="title">Table 1. async and sync events rules</caption>
<colgroup>
<col style="width: 20%;">
<col style="width: 40%;">
<col style="width: 40%;">
</col>
<thead>
<tr>
<th class="tableblock halign-left valign-top">Event method</th>
<th class="tableblock halign-left valign-top"><code>@Observes</code> notified</th>
<th class="tableblock halign-left valign-top"><code>@ObservesAsync</code> notified</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>fire()</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">yes, in the same thread</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>fireAsync()</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">no</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">yes, in a different thread</p></td>
</tr>
</tbody>
</col>
</col>
</colgroup>
<div class="sect1">
<h2 id="cdi-lite"><a class="anchor" href="#cdi-lite" />CDI Lite</h2>
<div class="sectionbody">
<div class="paragraph">
<p>As you know, CDI lite is one of the expected features for CDI 2.0.
Yet, adding it with the SE / EE split for 2.0 could bring a lot of glitches and could reveal itself a catastrophe without speaking of specific impl and TCK for it.</p>
</div>
<div class="paragraph">
<p>That’s why we choose to add it in the annexe of the spec as a proposal for a next CDI version.
Implementation will be allowed to create their CDI lite version based on this subset of CDI features:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>JSR 330 with CDI type resolution rules</p>
</li>
<li>
<p>CDI qualifiers usage</p>
</li>
<li>
<p>Producers and disposers</p>
</li>
<li>
<p>Programmatic lookup</p>
</li>
<li>
<p><code>@Singleton</code> and <code>@Dependent</code> pseudo-scopes support</p>
</li>
<li>
<p>SE bootstrap</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>We choose not to include events and spi to keep the impl lite.
Of course this could be change during our discussion.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="aop-on-producer-and-custom-beans"><a class="anchor" href="#aop-on-producer-and-custom-beans" />AOP on producer and custom beans</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The goal was to propose a solution to apply Interceptors and Decorators on produced beans or custom beans.
For producers we also have the problem of applying interceptor binding only on some method and not on the whole class.
We looked for a solution that could be used in both case and that was more an "advanced users" approach than an out of box one.</p>
</div>
<div class="paragraph">
<p>The idea is to provide a class or a built-in bean to help produced bean instances using AnnotatedType to allow override of annotation on instance class.
This suppose the addition of <code>AnnotatedTypeBuilder</code> to the SPI to ease the use of building a synthetic <code>AnnotatedType</code>.
This would follow the same idea than the <code>Unmanaged</code> class which provide a way to inject bean in a non bean (non managed) class.</p>
</div>
<div class="paragraph">
<p>That would give something like:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">public class MyAdvancedProducerBean {
public BeanInstanceBuilder<MyClass> bib = new BeanInstanceBuilder<>();
@Produces
@RequestScoped
public MyClass produceTransactionalMyClass() {
AnnotatedTypeBuilder<MyClass> atb = new AnnotatedTypeBuilder<>()
.readFrom(MyClass.class)
.addToMethod(MyClass.class.getMethod("performInTransaction")
, new TransactionalLiteral());
return bib.readFromType(atb.build())
.build(); //instance of the bean with requested interceptors / decorators
}
public void disposeMyClass (@Disposes Myclass td) {
bib.dispose(td);
}
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>A similar mechanism could be used in the <code>create()</code> method of custom beans.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="conclusion"><a class="anchor" href="#conclusion" />Conclusion</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Of course, all these points will be described in more detail in coming proposal documents.
You’ll only find here general ideas of what we like to propose.</p>
</div>
<div class="paragraph">
<p>We also worked on other points in Jira for clarification or fix.
This will go to the mailing list.</p>
</div>
<div class="paragraph">
<p>This post will be updated with new information or clarification if needed.</p>
</div>
</div>
</div></table></div></div>
http://www.cdi-spec.org/news/2015/07/03/CDI-2_0-EDR1-released.htmlCDI 2.0 Early Draft Review 1 released2020-09-18T08:53:43+02:002015-07-03T00:00:00+00:00
After eight months of work, the CDI 2.0 expert group is pleased to release this first draft of CDI 2.0 specification for community review. This draft contains important and long awaited features that will change CDI as we know it.
But these features are still proposals and we really need your feedback to know if the way we specified them fits your needs.
Let’s check what’s on the menu.
CDI runs now in Java SE
One of the oldest request was the support of Java SE in CDI. Since the beginning the two main implementations (JBoss Weld and Apache OpenWebBeans) proposed proprietary...
<div class="paragraph">
<p>After eight months of work, the CDI 2.0 expert group is pleased to release this first draft of <a href="https://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html" target="_blank">CDI 2.0 specification</a> for community review. This draft contains important and long awaited features that will change CDI as we know it.</p>
</div>
<div class="paragraph">
<p>But these features are still proposals and we really need your feedback to know if the way we specified them fits your needs.
Let’s check what’s on the menu.</p>
</div>
<div class="sect1">
<h2 id="cdi-runs-now-in-java-se"><a class="anchor" href="#cdi-runs-now-in-java-se" />CDI runs now in Java SE</h2>
<div class="sectionbody">
<div class="paragraph">
<p>One of the oldest request was the support of Java SE in CDI. Since the beginning the two main implementations (JBoss Weld and Apache OpenWebBeans) proposed proprietary solutions to use CDI in Java SE.</p>
</div>
<div class="paragraph">
<p>Then, Apache DeltaSpike came in and provided an absract solution to boot either implementations, but this wasn’t never standardized at spec level, until now…</p>
</div>
<div class="sect2">
<h3 id="why-this-important"><a class="anchor" href="#why-this-important" />Why this important?</h3>
<div class="paragraph">
<p>So, if implementation and a third party project already provide this Java SE support, what’s the big deal to have it at spec level? The answer is "increase adoption by other specifications".</p>
</div>
<div class="paragraph">
<p>A lot of Java EE specification provide a Java SE support (like JPA or JAX-RS). Since CDI doesn’t provide this support as well, they can’t rely totally on it since it is not available in Java SE.
So, the side effect of this new Java SE support will be a better CDI integration in Java EE. If we add to this a broader adoption by third parties framework, we see that the benefits for CDI and its users goes far beyond the simple feature.</p>
</div>
</div>
<div class="sect2">
<h3 id="preparing-java-se-support-api-split"><a class="anchor" href="#preparing-java-se-support-api-split" />Preparing Java SE support (API split)</h3>
<div class="paragraph">
<p>Adding such a straight forward feature to CDI seems quite easy on paper but, trust me, it wasn’t.</p>
</div>
<div class="paragraph">
<p>If you check the <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html" target="_blank">current 1.2 specification</a>, you’ll see that EJB is everywhere in the spec. You also have reference to JSF, servlet or Expression Language all accross the document.</p>
</div>
<div class="paragraph">
<p>So the first work was to split the spec to put he Java EE specific feature in a dedicated part to have all CDI core feature (no tie to other spec) in its own part. This specification has now 3 parts plus an introduction as explain in the <a href="https://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#_foreword" target="_blank">foreword section</a>.</p>
</div>
<div class="paragraph">
<p>This work was done as carefully as possible to avoid destroying, duplicating or modifying rules, yet, your double check here is most welcome to be sure that we didn’t forget something in the rewriting.</p>
</div>
<div class="paragraph">
<p>Yes it’s rather long work to read (or re-read) the whole specification but it’s also the ocasion to see it with a fresh eye with this new organisation. You migh want grab the <a href="https://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec-2.0.pdf" target="_blank">pdf version</a> (whose look has been updated) of the spec to go through it.</p>
</div>
</div>
<div class="sect2">
<h3 id="booting-cdi-in-java-se"><a class="anchor" href="#booting-cdi-in-java-se" />Booting CDI in Java SE</h3>
<div class="paragraph">
<p>After all this work (invisible for end users), we introduced the Java SE support by adding a bootstrap API for Java SE. The solution make use of already existing <a href="http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/CDIProvider.html" target="_blank"><code>CDIProvider</code></a> interface and <a href="http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/CDI.html" target="_blank"><code>CDI</code></a> class.</p>
</div>
<div class="paragraph">
<p>Code for booting CDI in Java SE looks like this:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">public static void main(String... args) {
try(CDI<Object> cdi = CDI.getCDIProvider().initialize()) {
// start the container, retrieve a bean and do work with it
MyBean myBean = cdi.select(MyBean.class).get();
myBean.doWork();
}
// shuts down automatically after the try with resources block.
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>Go check the <a href="https://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#bootstrap-se" target="_blank">Bootstrapping a CDI container in Java SE</a> chapter in the specification and tell us what do you think.</p>
</div>
</div>
<div class="sect2">
<h3 id="still-work-to-do"><a class="anchor" href="#still-work-to-do" />Still work to do</h3>
<div class="paragraph">
<p>Java SE support needs more work and we are still working on the feature. The two main aspect are:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><a href="https://issues.jboss.org/browse/CDI-529" target="_blank">work on bean discovery mode in SE</a></p>
</li>
<li>
<p><a href="https://issues.jboss.org/browse/CDI-530" target="_blank">work on context control in SE</a></p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Again, your feedback and ideas are most welcome to help us for these part specification.</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="ordering-event-observers"><a class="anchor" href="#ordering-event-observers" />Ordering event observers</h2>
<div class="sectionbody">
<div class="paragraph">
<p>One of the <a href="https://issues.jboss.org/browse/CDI-4" target="_blank">oldest requested feature</a> for CDI was resolved in this EDR : observer ordering.</p>
</div>
<div class="paragraph">
<p>The feature was simply design by using <code>@Priority</code> annotation (from commons annotation) and will be used like this:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">void afterLogin(@Observes @Priority(APPLICATION) LoggedInEvent event) { ... }</code></pre>
</div>
</div>
<div class="paragraph">
<p>The use of <code>@Priority</code> was rather obvious since we already use this annotaion for interceptor, decorator or alternatives activation and ordering. The only issue here is that the annotation only targets types right now. We asked for a review of JSR-250 to add parameter as accepted target for <code>@Priority</code>.</p>
</div>
<div class="paragraph">
<p>Check the <a href="https://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#observer_ordering" target="_blank">section dealing with observer ordering</a> to have all the details.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="asynchronous-events"><a class="anchor" href="#asynchronous-events" />Asynchronous events</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Another important feature requested by many of you. Introducing Asynchronous event wasn’t an easy thing, because we needed to keep backward compatibilty with existing events. We also wanted to leverage new asynchronous API in Java 8 to provide the most up to date approach in the spec.</p>
</div>
<div class="paragraph">
<p>The solution we choose was to introduce <code>@ObservesAsync</code> and add methods <code>fireAsync()</code> in the <code>Event</code> interface. So the exisitng observer (defined with <code>@Observes</code>) will stay synhcronous and new observer defined by <code>@ObservesAsync</code> will be called asynchronously if the event was triggered with <code>fireAsync()</code> (and won’t be called from a classical <code>fire()</code>).</p>
</div>
<div class="paragraph">
<p>So asynchronous event usage will look like this:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">@Inject Event<LoggedInEvent> loggedInEvent;
public void login() {
...
loggedInEvent.fireAsync( new LoggedInEvent(user) );
}
...
public void asyncAfterLogin(@ObservesAsync LoggedInEvent event) { ... }</code></pre>
</div>
</div>
<div class="paragraph">
<p>The best is to re-read <a href="https://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#events" target="_blank">all the event chapter</a> in the spec to get the details.</p>
</div>
<div class="sect2">
<h3 id="why-this-double-activation-is-needed"><a class="anchor" href="#why-this-double-activation-is-needed" />Why this double activation is needed?</h3>
<div class="paragraph">
<p>For the producer (<code>fire()</code>) side it’s rather obvious : we cannot magically change all synchronous event call to async. We need an handle on the work in progress (so a new method signature with <code>CompletionStage</code>), the payload mutation mechanism would break as all transactional events. So there’s no debate on <code>fireAsync()</code>.</p>
</div>
<div class="paragraph">
<p>On the observer side, the reason is for backward compatibility. CDI events are a great way to cross boundaries of our own code and activate unknown code at runtime in another module of the app (i.e. another jar) that we don’t own. This other code can be a framework, a code developed by an other team in a big project or a legacy jar that we don’t want to touch.</p>
</div>
<div class="paragraph">
<p>Imagine the following use cases (all code running on CDI 2)</p>
</div>
<div class="ulist">
<ul>
<li>
<p>I’m compiling in CDI 1.x and one of the Jar (framework for instance) already migrated to CDI 2.0 firing async event where it use to fire sync events. Without activation on the observer side, I have all the chance to see my observer break. And if I decide to upgrade to CDI 2.0 I must have a way to activate / deactivate async call on given observers</p>
</li>
<li>
<p>I’m compiling in CDI 2.0 but use <code>jar1</code> in CDI 1.0 and <code>jar2</code> in CDI 2.0 coming from other teams. <code>jar2</code> and <code>jar1</code> are old related pieces of code communicating the event. The guys in <code>jar2</code> had time to migrate to CDI 2.0 and switch most fire() to fireAsync(). Observer in jar1 will be called asynchronously if the default is to have async activated for all observers.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>These example looks like corner cases but the side effect will be that no framework developers will switch to fireAsync() for the sake of defensive programming. So async event would have a serious adoption problem withotu this double activation.
More than that, as we are designing a Java EE specification we must be committed to backward compatibility and cannot change behavior of old code, like it would do if we chose to not have activation on observer side.</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="other-change-corrections-and-clarifications"><a class="anchor" href="#other-change-corrections-and-clarifications" />Other change, corrections and clarifications</h2>
<div class="sectionbody">
<div class="paragraph">
<p>You can check the <a href="https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12311062&version=12327364" target="_blank">release notes</a> of this early draft to discover the more minor changes we also introduced in the spec.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="implementation-and-tck"><a class="anchor" href="#implementation-and-tck" />Implementation and TCK</h2>
<div class="sectionbody">
<div class="paragraph">
<p>TCK team and JBoss Weld team are currently working hard to provide a Reference Implementation for this draft. You’ll be notified as soon as there’ll be released.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="we-need-you"><a class="anchor" href="#we-need-you" />We need you</h2>
<div class="sectionbody">
<div class="paragraph">
<p>To go on on this Early draft, we really need your feedback. The review period will be launch in the coming days by the JCP and will run for 90 days. You can give your feedback in many way:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>By commenting this post</p>
</li>
<li>
<p>On the <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">mailing list</a></p>
</li>
<li>
<p>On our <a href="https://issues.jboss.org" target="_blank">Jira platform</a></p>
</li>
<li>
<p>or, if it’s rather short on <a href="https://twitter.com/cdispec" target="_blank">Twitter</a></p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Thank you for helping us making CDI one of the best programming model for Java and Java EE.</p>
</div>
</div>
</div>
http://www.cdi-spec.org/news/2015/02/23/CDI-2_0_-_A_glimpse_at_the_future.htmlCDI 2.0 - A glimpse at the future2020-09-18T08:53:43+02:002015-02-23T00:00:00+00:00
Introduction
Before we have a look at the changes in the upcoming CDI 2.0 specification, lets talk about where they come from. Did you know that they were provided by the community, so maybe by you?
Before the work on JSR 365 started, former expert group members, the expert group members of other specifications and the community were asked which changes they would like to see in CDI 2.0. 260 developers provided their feedback in the community survey. Based on these information, the 6 main topics were defined:
modularity,
enhancements of the event system,
improvements for interceptors and decorators,
CDI for Java SE,
usage of Java 8...
<div class="sect1">
<h2 id="introduction"><a class="anchor" href="#introduction" />Introduction</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Before we have a look at the changes in the upcoming CDI 2.0 specification, lets talk about where they come from. Did you know that they were provided by the community, so maybe by you?</p>
</div>
<div class="paragraph">
<p>Before the work on <a href="https://www.jcp.org/en/jsr/detail?id=365" target="_blank">JSR 365</a> started, former expert group members, the expert group members of other specifications and the community were asked which changes they would like to see in CDI 2.0. 260 developers provided their feedback in the community survey. Based on these information, the 6 main topics were defined:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>modularity,</p>
</li>
<li>
<p>enhancements of the event system,</p>
</li>
<li>
<p>improvements for interceptors and decorators,</p>
</li>
<li>
<p>CDI for Java SE,</p>
</li>
<li>
<p>usage of Java 8 features and</p>
</li>
<li>
<p>SPI and context enhancements.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The work on these topic is organized in 6 workshops, one for each main topic. This allows the members to focus their efforts and the group to work on several topics in parallel. The work of each workshop is tracked in a publicly available workshop document. You can find a reference to each document in the following paragraphs.</p>
</div>
<div class="paragraph">
<p>The 3.0.0.Alpha releases of Weld, the CDI reference implementation, provide prototype implementations for the discussed features. The goal is to create an early proof of concept and to give the community a chance to try the new features and to provide feedback.<br>
But please be aware, that these releases should not be used for production. They are only prototypes and the following releases are likely to contain incompatible changes.</br>
</p>
</div>
</div>
<div class="sect1">
<h2 id="main-topics-for-cdi-2-0"><a class="anchor" href="#main-topics-for-cdi-2-0" />Main Topics for CDI 2.0</h2>
<div class="sectionbody">
<div class="paragraph">
<p>OK, enough banter for now. Lets have a more detailed look at the current status of work and some new features in the following subsection.</p>
</div>
<div class="sect2">
<h3 id="modularity"><a class="anchor" href="#modularity" />Modularity</h3>
<div class="paragraph">
<p>One of the main topics for CDI 2.0 is modularization. In general, no one likes to consume a huge and heavy spec, if only a small part of it is required for the job. To make CDI easier to consume, the plan is to split the specification into different parts that provide different subsets of it. A project or JSR could then decide which parts it likes to use and define its dependencies accordingly.</p>
</div>
<div class="paragraph">
<p>The work on this topic is still in a very early state and so far, there are just some ideas on how the specification shall be modularized. The documented suggestion of 5 different parts that depend on each other will most likely not be the final version. <br>
The new idea is to split the specification into 3 parts: CDI full with Java EE support, CDI full and CDI light. CDI full with Java EE support will provide the full feature set of the specification. CDI full and CDI light will only provide a subset of it. The Java EE support will be missing in both of them. Additionally, the support for Contexts and AOP will be missing in CDI light. We will have to see, if this will be the final version.</br>
</p>
<div class="paragraph">
<p>These are the current ideas on how to create a modular CDI specification. If you like to get more details or follow future discussions on this topic, you can find the workshop document <a href="https://docs.google.com/document/d/1jzCuFQjtCSrnZGRAHjn0oknWvEaP3h0KizW1mHB4AZU/edit?usp=sharing" target="_blank">here</a>.</p>
</div>
</div>
<div class="sect2">
<h3 id="enhancements-of-the-events-system"><a class="anchor" href="#enhancements-of-the-events-system" />Enhancements of the events system</h3>
<div class="paragraph">
<p>The enhancement of the existing event mechanics seems to be in heavy demand of the community and is one of the bigger topics for CDI 2.0. The main features requested by the community were to support asynchronous events and to get a better control about events and event observers. There are several ideas that are discussed at the moment and the latest Weld 3.0.0 Alpha releases provided prototype implementations for some of them.</p>
</div>
<div class="paragraph">
<p>Lets have a look at two of the momentarily discussed features. And again, the work is still ongoing and everything can still change.</p>
</div>
<div class="sect3">
<h4 id="ordering-of-events"><a class="anchor" href="#ordering-of-events" />Ordering of events</h4>
<div class="paragraph">
<p>One of the requested enhancements is an option to order the event observers. The currently agreed solution is to use an approach similar to the priority definition for interceptors. The @Priority annotation can be used to define the priority of an event observer. The observers will process the event in ascending order of their priority. A working prototype for this feature was released with Weld 3.0.0.Alpha1. You can find more information about it in the <a href="http://weld.cdi-spec.org/news/2014/10/02/weld-300Alpha1/" target="_blank">release announcement</a>.</p>
</div>
</div>
<div class="sect3">
<h4 id="asynchronous-events"><a class="anchor" href="#asynchronous-events" />Asynchronous events:</h4>
<div class="paragraph">
<p>Up to now, events in CDI were processed synchronously. There are some workarounds to trigger asynchronous processing, e.g. using asynchronous EJBs, but this was outside the CDI specification and shall be changed with CDI 2.0. <br>
The Weld 3.0.0.Alpha3 release provides a working prototype, which adds the method fireAsync to the Event interface. The processing of an asynchronous event is similar to the processing of a synchronous one. The event object is mutable and thread-safe and the event observers will process the event in the defined order. You can read more about it in the <a href="http://weld.cdi-spec.org/news/2014/12/10/an-update-on-weld-3/">release announcement of Weld 3.0.0.Alpha3</a>.</br>
</p>
<div class="paragraph">
<p>You can get an overview about all discussed changes and ideas in the <a href="https://docs.google.com/document/d/1lFtgLm6hY-uECdA1r0Sfimq6vkVYThoUZsevPUaSP0E/edit" target="_blank">workshop document</a>.</p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="improvements-for-interceptors-and-decorators"><a class="anchor" href="#improvements-for-interceptors-and-decorators" />Improvements for interceptors and decorators</h3>
<div class="paragraph">
<p>There are several enhancements to interceptors and decorators in CDI that are planned for CDI 2.0. Some of them are to support AOP on custom or produced beans, to support AOP on inner calls and to improve the interceptor chaining. The work on these topics has not started yet. But there are some small enhancements that were already implemented with Weld 3.0.0.Alpha1. <br>
As Jozef Hartinger described in his <a href="http://weld.cdi-spec.org/news/2014/10/02/weld-300Alpha1/" target="_blank">release announcement</a>, support for repeatable annotations was added for qualifiers and interceptor bindings. And the <em>javax.interceptor.InvocationContext</em> interface was extended to make it easier to access the interceptor binding in the interceptor.</br>
</p>
<div class="paragraph">
<p>You will find more information about it in the <a href="https://drive.google.com/open?id=10iexiDfMT9tYaUPa2cGiw4P68VG_bryDIS0DKzP1ils&authuser=0" target="_blank">workshop document</a> as soon as the work has started.</p>
</div>
</div>
<div class="sect2">
<h3 id="cdi-for-java-se"><a class="anchor" href="#cdi-for-java-se" />CDI for Java SE</h3>
<div class="paragraph">
<p>CDI requires an up and running CDI container to process its components. This is usually no problem in an Java EE environment because the application server is taking care of the CDI container. But this is different in an Java SE environment, where the container has to be booted by the application. The main problem is, that the specification does not define an API to boot the container. Therefore Weld and Open Web Beans provide its own proprietary APIs to do it and <a href="http://javaeesquad.blogspot.be/2014/12/cdi-for-java-se-already-standardised.html" target="_blank">Apache DeltaSpike offers an uniform API</a> on top of that. Beginning with CDI 2.0 the start of the container shall be defined in the standard.</p>
</div>
<div class="paragraph">
<p>The work on this topic is still ongoing and there are several open questions that need to be answered in the upcoming discussions. You can read about it in the <a href="https://drive.google.com/open?id=1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw&authuser=0" target="_blank">workshop document</a>.</p>
</div>
</div>
<div class="sect2">
<h3 id="usage-of-java-8-features"><a class="anchor" href="#usage-of-java-8-features" />Usage of Java 8 features</h3>
<div class="paragraph">
<p>Java 8 was released in March 2014 and is therefore not used by the Java EE 7 specifications which were released in 2013. This will change with Java EE 8 and this means that CDI 2.0 can also make use of the new features. <br>
The discussions about the influence of the new Java features on CDI are still in an early state, but there are several JEPs that seem to be applicable to improve the specification. Some of them, like the CompletionStage API and repeating annotations, are already used in the proposals for <a href="http://weld.cdi-spec.org/news/2014/12/10/an-update-on-weld-3/#_asynchronous_events" target="_blank">asynchronous events</a> and <a href="http://weld.cdi-spec.org/news/2014/10/02/weld-300Alpha1/#_repeatable_qualifiers_and_interceptor_bindings" target="_blank">repeatable interceptor bindings</a>. But the usage of the new Java 8 features will not be limited to the new CDI features, there will also be talks on how to improve the existing parts of the specification. <br>
The current ideas can be found in this <a href="https://drive.google.com/open?id=1KUaxXIXJ_r-h5UJGIij6I4vrLS7uXkeeeZr2SaRipWQ&authuser=0" target="_blank">document</a>.</br>
</br>
</p>
<div class="sect2">
<h3 id="spi-and-context-enhancements"><a class="anchor" href="#spi-and-context-enhancements" />SPI and context enhancements</h3>
<div class="paragraph">
<p>The work on SPI changes has also not started yet. Some goals of the CDI 2.0 specification will be to improve the access to all meta data created by CDI and to provide a way to add beans at runtime. The requested changes to provide a better control about contexts, especially to activate and deactivate them, will also require some SPI enhancements.<br>
An additional huge topic will be the changes caused by the adoption of Java 8 and how to keep the SPI binary backward compatible.<br>
The changes will be described in the <a href="https://drive.google.com/open?id=1aK3aIQG-W9D72Ti9fj0xLFNmqxQtYyy_vjc6QgN3Z2Y&authuser=0" target="_blank">workshop document</a>.</br>
</br>
</p>
</div>
</div>
<div class="sect1">
<h2 id="schedule"><a class="anchor" href="#schedule" />Schedule</h2>
<div class="sectionbody">
<div class="paragraph">
<p>As described in the previous paragraphs, the work on the CDI 2.0 specification is ongoing and there are lots of things that need further discussions. An early draft of the specification, which will contain the most stable new features, shall be completed in Q1 of 2015. The public review shall start in Q3 of 2015 and provide feedback for the final release. The final version of the CDI 2.0 specification shall be released in Q1 of 2016.</p>
</div>
</div>
</div></div></div></div></div></div></div></div></div>
http://www.cdi-spec.org/news/2014/10/20/CDI-2_0-first-face-to-face-meeting-feedback.htmlCDI 2.0 first Face to face meeting feedback!2020-09-18T08:53:43+02:002014-10-20T00:00:00+00:00
Last week we had the first CDI 2.0 Face to Face meeting in Brno (Czech Republic). Check what was discussed and the first CDI 2.0 orientations
Meeting Agenda
As you may know, CDI 2.0 project was launched only six weeks ago, so we are still in early discussion stage regarding CDI 2.0 design. Yet our workshop organisation was a good entry point to start going in more deep discussion. So we based our discussion on existing workshop documents. Here are the main decisions that came out from our discussion.
Parts introduction
Parts concept is not the most visible change we would introduce in CDI...
<div class="paragraph">
<p>Last week we had the first CDI 2.0 Face to Face meeting in Brno (Czech Republic). Check what was discussed and the first CDI 2.0 orientations</p>
</div>
<div class="sect1">
<h2 id="meeting-agenda"><a class="anchor" href="#meeting-agenda" />Meeting Agenda</h2>
<div class="sectionbody">
<div class="paragraph">
<p>As you may know, CDI 2.0 project was launched only six weeks ago, so we are still in early discussion stage regarding CDI 2.0 design. Yet our <a href="http://www.cdi-spec.org/news/2014/10/06/CDI-20_working_method/" target="_blank">workshop</a> organisation was a good entry point to start going in more deep discussion. So we based our discussion on existing workshop documents. Here are the main decisions that came out from our discussion.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="parts-introduction"><a class="anchor" href="#parts-introduction" />Parts introduction</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Parts concept is not the most visible change we would introduce in CDI 2.0 but since it’s probably the one with more impact on spec organisation, we started with this point to know if we should go in that direction. That answer was <strong>yes</strong>.
We also decided that each part would be independent from the other (i.e a bigger part wouldn’t depend from a smaller one but would integrate it) to solve API splitting issues. Having this principles accepted we talked about the possible parts and their content:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>CDI Light: a lightweight version of CDI without Normal Scopes, Interceptors and Decorators that would allow proxy-free implementations. We worked on the API present in this Part, you can have a look to what we proposed on this <a href="https://github.com/antoinesd/cdi-spec/tree/CDI_20_LIGHT" target="_blank">branch</a></p>
</li>
<li>
<p>CDI Full: CDI as we know it today except for all the other spec integration (servlet, JSF, EJB, etc…).</p>
</li>
<li>
<p>CDI Java EE : CDI full including integration with other specs</p>
</li>
</ul>
</div>
</div>
</div>
<div class="sect1">
<h2 id="events-enhancement"><a class="anchor" href="#events-enhancement" />Events enhancement</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The 2 main topics here were ordering and asynchronous events.</p>
</div>
<div class="sect2">
<h3 id="asynchronous-events"><a class="anchor" href="#asynchronous-events" />Asynchronous events.</h3>
<div class="paragraph">
<p>The main idea was to adopt a different approach than the one in EJB today. Instead of using a <code>@Asynchronous</code> annotation and manage a <code>Future<T></code> to deal with he end of asynchronous treatment, we looked for a way to provide callback to the event trigering.</p>
</div>
<div class="paragraph">
<p>The idea could be to add a <code>fireAsync()</code> method to the <code>Event<T></code> and use Java 8 lambdas and add a functional interface like this :</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">@FunctionalInterface
public interface EventCallBack<T> {
void doCallback(T callBack);
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>and use later like this</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">@Inject Event<Payload> evt;
public void fireAsyncWithCallBack() {
evt.fireAsync(new Payload(), callBack -> System.out.println("Job done”));
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>Off course this approach has to be more deeply investigate (we’ll do it on our coming event meeting) but it has a lot of advantages :</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Introduce a more modern approach of async events processing like we have in other framework or technologies</p>
</li>
<li>
<p>Complete the EJB approach instead of duplicating it</p>
</li>
<li>
<p>Avoid asking Java EE EG to extract @Asynchronous form EJB to put it somewhere else (where?)</p>
</li>
</ul>
</div>
</div>
<div class="sect2">
<h3 id="events-priority"><a class="anchor" href="#events-priority" />Events priority</h3>
<div class="paragraph">
<p>Discussion on event priority was open some weeks ago. We tried to have a fresh look to the idea. The main point was about using <code>@Priority</code> annotation or not. The question is still not closed but we’re more in favor of the use of a value in <code>@Observes</code> annotation. This value would give the order of the observer (the lowest being the first).
The main reason to choose this approach instead of @Priority is the fact that while being part of java common annotation (JSR 250) spec, @Priority is not present in Java SE. So using it would :</p>
</div>
<div class="ulist">
<ul>
<li>
<p>force us to ask for JSR 250 Maintenance release to allow priority on paramaters</p>
</li>
<li>
<p>add an extra dependency jar (for only one annotation) when using CDI Light in Java SE which seems against our "light" goal</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The <code>@Observes</code> evolution evolution would give something like:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">public void firstObserver(@Observes(1) Payload pl) {}
public void secondObserver(@Observes(2) Payload pl) {}</code></pre>
</div>
</div>
<div class="paragraph">
<p>Priority value provided in <code>javax.interceptor.Interceptor.Priority</code> would be duplicated in CDI to avoid useless dependency on Interceptor spec while keeping the same approach / values.
This ordering could be also used to order step in extensions.</p>
</div>
</div>
<div class="sect2">
<h3 id="event-range"><a class="anchor" href="#event-range" />Event Range</h3>
<div class="paragraph">
<p>The idea behind event range would to provide a "scope" to events (i.e package, war, ear). It would prepare CDI event to become a server wide eventing system.
The discussion came to the conclusion that while it’s rather easy to implement, it’s usage could be quite cumbersome.
The idea was not discarded but we thought it was a good idea to check with community if the need was real.</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="interceptors-and-decorators-aop-enhancement"><a class="anchor" href="#interceptors-and-decorators-aop-enhancement" />Interceptors and Decorators (AOP) enhancement</h2>
<div class="sectionbody">
<div class="paragraph">
<p>There were a lot of discussions around enhancing interceptors and decorators. You’ll find the main topics below.</p>
</div>
<div class="sect2">
<h3 id="aop-on-custom-beans-and-producers"><a class="anchor" href="#aop-on-custom-beans-and-producers" />AOP on custom beans and producers</h3>
<div class="paragraph">
<p>Conclusion was that it is doable but with certain limitations. Among them the fact that an interceptor on producer would be applied on all method of it (no obvious solution to target specifc methods).</p>
</div>
<div class="paragraph">
<p>We also discussed the syntax for binding interceptor to a produced bean. if you consider this code:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">@Produces
@Loggable
public Foo produceMap() {
return new Foo();
}</code></pre>
</div>
</div>
<div class="paragraph">
<p><code>@Loggable</code> interceptor binding is bound to the method not the produced bean. We have to find an easy way to bind the interceptor to the produced bean.
The only solution we found was to use a Stereotype with the interceptor binding and put it on the producer. Not a direct solution but rather elegant.</p>
</div>
</div>
<div class="sect2">
<h3 id="aop-on-internal-call-vs-self-injection-pattern"><a class="anchor" href="#aop-on-internal-call-vs-self-injection-pattern" />AOP on internal call vs self injection pattern</h3>
<div class="paragraph">
<p>We already discussed about supporting AOP on call make in the same bean (calling intercepted B method from method A with interceptor triggering).
After discussion, it seemed very difficult to introduce this new feature and AOP support on produced and custom beans at the same time. So the idea was to ease the use of self injection pattern, providing something like this.</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">public class MyBean {
@Inject
Self<MyBean> mySelf;
@Loggable
public methodB() {
...
}
public methodA() {
mySelf.get().methodB();
}
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>less elegant than having it directly on internal call but still useful.</p>
</div>
</div>
<div class="sect2">
<h3 id="other-aop-topics"><a class="anchor" href="#other-aop-topics" />Other AOP topics</h3>
<div class="paragraph">
<p>We also discussed about the following topics:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><strong>relaunching the idea of supporting decorator without interface</strong> like it was requested in <a href="https://issues.jboss.org/browse/CDI-403" target="_blank">CDI-403</a> and before that in <a href="https://issues.jboss.org/browse/CDI-224" target="_blank">CDI-224</a>.</p>
</li>
<li>
<p><strong>standardise the <a href="https://deltaspike.apache.org/documentation/partial-bean.html">partial bean</a> feature from Deltaspike</strong>. For those who don’t know this feature an example can be found <a href="https://github.com/jboss-developer/jboss-wfk-quickstarts/tree/2.6.0.Final/deltaspike-partialbean-advanced" target="_blank">here</a>.</p>
</li>
</ul>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="java-se-support"><a class="anchor" href="#java-se-support" />Java SE support</h2>
<div class="sectionbody">
<div class="paragraph">
<p>We had a long discussion on Java SE support in CDI 2.0. To decide that we should just provide a class like this:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="highlightjs highlight nowrap"><code class="language-java" data-lang="java">public class ContainerBoot {
/**
* Simple boot
*/
static BeanManager initialize() {
...
}
/**
* Boot with parameters
*/
static BeanManager intialize(Map<?,?>) {
...
}
void shutdown() {}
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>Discussions are still going on on this topic.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="spi-enhancement"><a class="anchor" href="#spi-enhancement" />SPI enhancement</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Last but not least we also discussed about SPI enhancement. The main topic were:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><strong>Give the possibility to modify/register beans at runtime</strong>. The majority of present people were against this new feature. The ones in favor obtained that the door wouldn’t be closed now and that the community would be consulted to see if this need was "real". So we’ll be back on this feature and if you want to see it, stay tune to give it your support when we’ll ask for it.</p>
</li>
<li>
<p><strong>Add SPI to activate/deactivate contexts</strong>. Right now built-in context cannot be activated / deactivated by third parties, forcing them to create their own implementation of such contexts instead of using the one provided by their implementation. This small modification will greatly ease CDI advanced integration in other spec or frameworks.</p>
</li>
<li>
<p><strong>Add helpers to create CDI meta-data</strong>. Today it’s not very convenient to create an <code>AnnotatedType</code> or a custom <code>Bean</code>. We decided to explore the introduction of helpers inspired by Deltaspike Builders. They would be provided by lifecycle event</p>
</li>
</ul>
</div>
</div>
</div>
<div class="sect1">
<h2 id="conclusion"><a class="anchor" href="#conclusion" />Conclusion</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Here are the main topics we discussed during these 2 days. Other small feature will came to JIRA later. At this point there was only orientation and no final decision on any subject. So the door is still open for these as well as new feature. So don’t hesitate to give your advice andv your contribution to our <a href="http://www.cdi-spec.org/">workshop</a> or <a href="https://issues.jboss.org/browse/CDI" target="_blank">Jira server</a>.</p>
</div>
</div>
</div>
http://www.cdi-spec.org/news/2014/10/06/CDI-20_working_method.htmlWorking method for CDI 2.02020-09-18T08:53:43+02:002014-10-06T00:00:00+00:00
Work on CDI 2.0 started at the beginning of september. As you may guess, specifying and releasing this new major version is a big challenge.
To put all chance on our side we are looking for a strong commitment from the community (as explained in our previous post). That’s why the way we’ll be organised is very important.
Thus, when we started thinking about our working method we came up with the following requirements:
Keep the big picture of the spec in mind while working on all detail of each new / modified features
Have the right balance between "ideal specification" and the "specification...
<div class="paragraph">
<p>Work on CDI 2.0 started at the beginning of september. As you may guess, specifying and releasing this new major version is a big challenge.</p>
</div>
<div class="paragraph">
<p>To put all chance on our side we are looking for a strong commitment from the community (as explained in our <a href="http://www.cdi-spec.org/news/2014/08/26/CDI-20_needs_you/">previous post</a>). That’s why the way we’ll be organised is very important.
Thus, when we started thinking about our working method we came up with the following requirements:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Keep the big picture of the spec in mind while working on all detail of each new / modified features</p>
</li>
<li>
<p>Have the right balance between "ideal specification" and the "specification only driven by implementation" approaches</p>
</li>
<li>
<p>Be able to welcome new contributors (even casual ones) without loosing them in spec history or advanced technical details at the beginning</p>
</li>
<li>
<p>Give visibility to third party (other JSR or future implementor) of the spec without forcing them to follow our ML, IRC, JIRA</p>
</li>
<li>
<p>Get feedback from the community easily while designing the spec</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>To satisfy these points we came to the idea of creating different workshop on big CDI topics (existing and new). To begin we identified these workshops:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Parts (modularity) : how we can make CDI more modular by extracting sub part in the spec to allow it to grow without becoming bloated</p>
</li>
<li>
<p>Java SE support : how CDI should work in Java SE and what SPI should we add or standardise to ease its integration in home brewed stacks</p>
</li>
<li>
<p>Events enhancement : bringing asynchronicity or ordering to events. Can it be extended to all Java EE</p>
</li>
<li>
<p>Interceptor & Decorator : AOP support on produced or custom bean. Work with interceptor spec to add AOP on inner call</p>
</li>
<li>
<p>SPI enhancement for integration : give access to all metadata produced by the container, give control of CDI from outside code, support Bean addition / modification @ Runtime</p>
</li>
<li>
<p>Contexts enhancement : go beyond the the thread-bound request-response model used by context today to support new application architecture</p>
</li>
<li>
<p>Java 8 enhancement : see how new features in java 8 (type annotation, annotation repetition, lambdas, streams, default methods, type inference…) could enhance CDI in existing and new features.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>To ease this big picture approach we also adopted this following step to deal with each workshop:</p>
</div>
<div class="olist arabic">
<ol class="arabic">
<li>
<p>Blueprint draft : the workgroup lead propose a draft document describing his global idea of how the future should work</p>
</li>
<li>
<p>Draft discussion The draft is commented, amended, enhanced by the group which can react to the doc by proposing new ideas. and When people feel ready by the EG</p>
</li>
<li>
<p>Detailled task / requirement: after the discussion, each adopted concept are translated in on or more tickets in our Jira to follow their realisation to start more detailled discussion</p>
</li>
<li>
<p>Spec and TCK enhancement: each task is translated to the new specification document and translated to the TCK</p>
</li>
</ol>
</div>
<div class="paragraph">
<p>Of course these steps are more guidelines than a strong workflow, it’s a way to ease contribution not constraint it. It will probably evolve with time.</p>
</div>
<div class="paragraph">
<p>On our <a href="http://www.cdi-spec.org/">home page</a> you’ll find the list of each workshop and their current status and links (working doc, Jira EPICS, etc…). Please feel free to check these links and give your feedback and don’t heistate to contribute with your idea on this documents.</p>
</div>
http://www.cdi-spec.org/news/2014/08/26/CDI-20_needs_you.htmlCDI 2.0 needs you2020-09-18T08:53:43+02:002014-08-26T00:00:00+00:00
The work on CDI 2.0 specification is about to start in the coming weeks. We have a lot of ambitious features on the table as you can check in our previous article, but we also have only 18 months to specify and implement them. Without community help, we probably won’t be able to do all the change we are planning, so your contribution is precious to us. In this post I’ll explain the multiple ways you can be part of it, even if you only have a few hours a week to help us and/or are not a CDI, JCP...
<div class="paragraph">
<p><span class="image" style="float: left"><img src="http://www.cdi-spec.org/images/UncleDuke.png" alt="Uncle Duke" width="150" /> The work on CDI 2.0 specification is about to start in the coming weeks. We have a lot of ambitious features on the table as you can check in our previous <a href="http://www.cdi-spec.org/news/2014/07/28/what-s-in-CDI-20-jsr-proposal/" target="_blank">article</a>, but we also have only 18 months to specify and implement them. Without community help, we probably won’t be able to do all the change we are planning, so your contribution is precious to us. In this post I’ll explain the multiple ways you can be part of it, even if you only have a few hours a week to help us and/or are not a CDI, JCP or a Java expert. Let’s check the 3 main question most of you have regarding contribution and try to answer them:</span>
</p>
<div class="ulist">
<ul>
<li>
<p>Why should I contribute?</p>
</li>
<li>
<p>Is it possible for me to contribute?</p>
</li>
<li>
<p>How do I start contributing?</p>
</li>
</ul>
</div>
<div class="sect1">
<h2 id="why-should-i-contribute-to-cdi-2-0"><a class="anchor" href="#why-should-i-contribute-to-cdi-2-0" />Why should I contribute to CDI 2.0?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Contributing to a specification like CDI looks like any other Open Source contribution (by the way CDI specification and deliverable are under the <a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">Apache License version 2</a>) yet it’s very different. The following points will detail these differences.</p>
</div>
<div class="sect2">
<h3 id="working-on-architecture-and-concepts-first"><a class="anchor" href="#working-on-architecture-and-concepts-first" />Working on Architecture and concepts first</h3>
<div class="paragraph">
<p>The biggest difference between working on a standard OSS project and a specification is probably the fact that the first job is to write detailled documentation (the specification document).
Regarding specification document, the content should be very accurate and respect a certain set of rules among them:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>use an homogenous style in simple yet understandable english across the doc,</p>
</li>
<li>
<p>as specification cannot be changed easily, the work must be very precise, consequences of a choice must be analysed deeply and ambiguities in definitions shouldn’t exist,</p>
</li>
<li>
<p>stick to <a href="http://docs.oracle.com/javase/specs/jls/se8/html/index.html" target="_blank">Java language Specification</a> (JSL) rules and terms,</p>
</li>
<li>
<p>avoid <a href="http://en.wikipedia.org/wiki/Denormalization">denormalization</a>: the specification should use cross references to point to an existing definition instead of duplicating it,</p>
</li>
<li>
<p>avoid mentioning how features should be implemented while keeping in mind that specified features will have to be implemented at the end.</p>
</li>
</ul>
</div>
</div>
<div class="sect2">
<h3 id="participating-to-code-writing"><a class="anchor" href="#participating-to-code-writing" />Participating to code writing.</h3>
<div class="paragraph">
<p>Specification is useless without implementations. So after (and sometimes while) thinking, comes code writing. First the API, the code that all specifications will have to implement and then as a proof of concept of the specification we have to provide the RI (reference implementation) and TCK (Technology Compatibility Kit) which is mandatory for developing other implementations. So you can also be useful by contributing to <a href="http://weld.cdi-spec.org/">JBoss Weld</a> and the <a href="https://github.com/cdi-spec/cdi-tck">CDI TCK</a> which is the translation of the specification in a test suite. Off course these will ask more time and probably more skills for a contribution.</p>
</div>
</div>
<div class="sect2">
<h3 id="contributing-to-the-future-of-java-ee-and-java-se"><a class="anchor" href="#contributing-to-the-future-of-java-ee-and-java-se" />Contributing to the future of Java EE and Java SE</h3>
<div class="paragraph">
<p>CDI 2.0 will be part of Java EE 8 but also targets Java SE. Therefore, we’d like to make CDI the Dependency Injection standard for Java. It already plays this role for Java EE. So contributing to the CDI 2.0 specification is a way to be part to the future of Java and Java applications architecture.</p>
</div>
</div>
<div class="sect2">
<h3 id="being-at-the-source-of-a-lot-of-other-projects"><a class="anchor" href="#being-at-the-source-of-a-lot-of-other-projects" />Being at the source of a lot of other projects</h3>
<div class="paragraph">
<p>Working on CDI specification is also a way to indirectly work at (and thus, have impact on) other projects linked to it. The implementations (Apache OpenWebBeans and JBoss Weld) are off course the obvious ones, but today there are a lot of other open source frameworks or projects out there based on CDI. <a href="http://deltaspike.apache.org/" target="_blank">Apache Deltaspike</a>, <a href="http://www.vraptor.org/" target="_blank">VRaptor</a> or <a href="http://www.openbravo.com/" target="_blank">Openbravo</a> are some example of these (you can also consider most of JBoss Java frameworks which use CDI to be integrated).
Working on CDI is a way to help these projects to become better or give you the knowledge to contribute to them in the future to help them getting the best of CDI 2.0 when it will be released.</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="is-it-possible-for-me-to-contribute"><a class="anchor" href="#is-it-possible-for-me-to-contribute" />Is it possible for me to contribute?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Most people disqualified themselves when it comes to contribute to a JSR. The 3 most frequent reason given are:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>the technical level,</p>
</li>
<li>
<p>the lack of time or,</p>
</li>
<li>
<p>the "paperwork" tied to such a contribution.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Let’s review these "good" excuses that could make one thinks "contributing is not for me"</p>
</div>
<div class="sect2">
<h3 id="technical-level"><a class="anchor" href="#technical-level" />Technical level</h3>
<div class="paragraph">
<p>Ok, if you are an absolute beginner in Java and CDI, it will be hard to help without making others loose their time. But as you’re reading these lines, you are probably not an absolute beginner ;). One of our goal on CDI 2.0 is to make the specification as easy as possible to read. So even if you are not a top notch Java specialist, your reading skill and feedback on badly written, ambiguous or hard to understand part will be very precious to the Expert Group.
Regarding Java Level, CDI 2.0 will leverage a lot of new features coming with Java SE 8 on which most of the contributors will have very little experience. So, on this topic specialists will be the exception.
To make short, the minimum level to contribute is to have a reasonable knowledge on Java (enough to know your unknown and where to look to learn), have already used CDI in development, have a good knowledge of its features (DI, Events, AOP, Extensions…) and be able to read english.
That makes a lot of people qualified to help.</p>
</div>
</div>
<div class="sect2">
<h3 id="time"><a class="anchor" href="#time" />Time</h3>
<div class="paragraph">
<p>From the previous point you can understand that there is no minimum amount of time for contribution. For instance you can read a specification chapter and propose corrections or remarks on it, it will take you 2 or 3 hours on the 18 months of the specification. Now the best would be to provide a few hours a week. To help people that want to contribute and don’t have much time, we’ll try to provide a monthly synthesis of topics worked on the project to spare their time and avoid the "I’d like to do something but I don’t have time to dig thru all the mailing list and Jira message to figure out what to do". These reports will also be useful for the EG members to have a big picture vision of the work regulary.</p>
</div>
</div>
<div class="sect2">
<h3 id="paper-work"><a class="anchor" href="#paper-work" />Paper work</h3>
<div class="paragraph">
<p>To be officially enrolled on a JCP Expert Group requires a little paper work. You’ll have to create an account on <a href="http://jcp.org" target="_blank">jcp.org</a> and sign the Java Specification Agreement (JSPA). You’ll probably have to ask you employeer an agreement to contribute. And then ask the spec lead to be part of the JSR. On the JSR side, we never refused a member in the EG in the past and plan to continue like that for the new JSR</p>
</div>
<div class="paragraph">
<p>The good news is that we also accept non official contributions as any other Open Source project using ASL2. So if you don’t feel like signing JCP stuff, you can still participate to discussion on the Mailing list, the IRC channel or our JIRA site. You can even send pull request on the project. The only difference will be that you won’t be mentioned as a member of the expert group on the JCP website.</p>
</div>
<div class="paragraph">
<p>So to make short. You can start contributing with no paper work. Stay anonymous during all the project or decide to officially join the EG at any time before the end of the JSR. The only limit would be if you start doing big contribution. In this case we’ll probably ask you to join EG to avoid any future IP issues.</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="how-do-i-start-contributing"><a class="anchor" href="#how-do-i-start-contributing" />How do I start contributing?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The best place to start is probably the <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">Mailing List</a>, or if you want a more informal you can begin with the IRC channel(#cdi-dev on freenode). All the information regarding communication channel of the spec is detailled on the <a href="http://www.cdi-spec.org/contribute">contribute</a> page.</p>
</div>
<div class="paragraph">
<p>You also should start reading the <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec-1.2.pdf" target="_blank">existing specification</a> to become familiar with its content and its style.</p>
</div>
<div class="paragraph">
<p>Finally, as the specification is written in asciidoc (with the excellent asciidoctor implementation), you should also start learning it. The best place is probably the <a href="http://asciidoctor.org/docs/user-manual/" target="_blank">Asciidoctor user manual</a>. As we’re using asciidoctor maven plugin to generate the doc you won’t have to install asciidoc toolchain, only Maven. You’ll also nedd a text editor with optionally plugins to help writing asciidoc. <a href="https://atom.io/">Atom editor</a> with asciidoc language and asciidoc preview plugins is a good solution, but there are plenty of others depending on your taste and current tools.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="what-s-next"><a class="anchor" href="#what-s-next" />What’s next?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>We are currently preparing the organization of the work around the specification. The goal is to be as efficient as possible regarding contribution. The Mailing List is the best place to stay tuned. In the meantime you can do "homework" with the existing material.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="conclusion"><a class="anchor" href="#conclusion" />Conclusion?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>We are trying to make CDI 2.0 a very open specification to give to the community the possibility to contribute easily to this great project. We are thrilled to count you onboard for any contribution (big or small) you’ll be able to do, making CDI 2.0 your specification.</p>
</div>
</div>
</div></div>
http://www.cdi-spec.org/news/2014/07/28/what-s-in-CDI-20-jsr-proposal.htmlWhat's in CDI 2.0 JSR proposal?2020-09-18T08:53:43+02:002014-07-28T00:00:00+00:00
A few days ago, we submitted the official proposal for CDI 2.0. This new version is focused on 2 main goal:
Adding Java SE support to CDI
Add modularity to CDI to ease its integration with other specification or framework.
Off course a lot of feature and enhancement will come from this 2 goals and we’ll add a few more if possible. Let’s check what’s on the menu.
A new name
Not the most important part, but as we plan supporting Java SE, we slightly changed the name of the specification. Previously, the full name of CDI was: Contexts and Dependency Injection for Java EE....
<div class="paragraph">
<p>A few days ago, we submitted the official proposal for CDI 2.0. This new version is focused on 2 main goal:</p>
</div>
<div class="olist arabic">
<ol class="arabic">
<li>
<p>Adding Java SE support to CDI</p>
</li>
<li>
<p>Add modularity to CDI to ease its integration with other specification or framework.</p>
</li>
</ol>
</div>
<div class="paragraph">
<p>Off course a lot of feature and enhancement will come from this 2 goals and we’ll add a few more if possible. Let’s check what’s on the menu.</p>
</div>
<div class="sect1">
<h2 id="a-new-name"><a class="anchor" href="#a-new-name" />A new name</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Not the most important part, but as we plan supporting Java SE, we slightly changed the name of the specification. Previously, the full name of CDI was: <strong>Contexts and Dependency Injection for Java EE</strong>. The proposed new name is: <strong>Contexts and Dependency Injection for Java</strong>. So to SE we go ;).</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="new-features-and-enhancement-proposed"><a class="anchor" href="#new-features-and-enhancement-proposed" />New features and enhancement proposed</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Beyond the two main points introduced above (or because of them), we have the following features in mind</p>
</div>
<div class="sect2">
<h3 id="identify-the-java-ee-part-in-cdi"><a class="anchor" href="#identify-the-java-ee-part-in-cdi" />Identify the Java EE part in CDI</h3>
<div class="paragraph">
<p>We have a lot of work to prepare the Java SE support in CDI. The first will be to check what’s is pure CDI and what’s is link to Java EE.
So for CDI 2.0, The specification and TCK require a significant overhaul to be split into two parts.</p>
</div>
<div class="olist arabic">
<ol class="arabic">
<li>
<p>Part 1: The core CDI programming model (usable in EE and SE as well)</p>
</li>
<li>
<p>Part 2: Java EE integrations for CDI (i.e. all the feature that won’t be available when working in Java SE).</p>
</li>
</ol>
</div>
<div class="paragraph">
<p>Some of the splitting is straight forward (thre’s no EJB in Java SE), other could bring some discussion and extra work (do we want to support <code>@Transactional</code> in Java SE and how?).</p>
</div>
</div>
<div class="sect2">
<h3 id="defining-a-portable-bootstrap-api-for-cdi"><a class="anchor" href="#defining-a-portable-bootstrap-api-for-cdi" />Defining a portable bootstrap API for CDI.</h3>
<div class="paragraph">
<p>Currently CDI does not define an API for bootstrap, instead relying on a Java EE deployment to start the container.
To add support for Java SE, we really need such an API. Additionally, we would like to introduce a programmatic API for binding beans, allowing much greater flexibility for portably wiring a container.</p>
</div>
</div>
<div class="sect2">
<h3 id="enhance-the-cdi-context-model"><a class="anchor" href="#enhance-the-cdi-context-model" />Enhance the CDI context model</h3>
<div class="paragraph">
<p>The context model in CDI is based around the thread-bound request-response model. This model is more prevalent in web applications than elsewhere, and, also is less pervasive than it once was. We would like to overhaul the context model to allow the application or container to portably push the active context to CDI when it requires the use of CDI. This change would be largely transparent to applications, and we might want to consider an API facade over it.</p>
</div>
</div>
<div class="sect2">
<h3 id="introduce-modularity-to-cdi"><a class="anchor" href="#introduce-modularity-to-cdi" />Introduce modularity to CDI.</h3>
<div class="paragraph">
<p>One of the most often given reason by other JSR or frameworks to limit their CDI adoption is the size of the specification. Too big, too many features.
CDI is becoming an important component model in Java EE, and we think that learning from the experience of long running specifications of specifications (like EJB) is important. Before we starting adding features to CDI, we want to see if we can introduce “parts”, to avoid creating a spec that gives the impression of being big and heavy.
There’s already some preparation work around this topic. For instance JAX-RS asked if it was possible to only have only the event part of CDI. Other discussion with the future java config specification are dealing with a "type discovery" part.
One of the most asked module is a lightweight container, which takes the annotations specified by the @Inject specification, defines the behavior of the container (which @Inject failed to do), and adds a couple of popular features from CDI such as producer methods. This will allow much wider adoption of CDI in the Java world, and provide a great stepping stone between Java SE, a servlet container, OSGi and a full Java EE server.</p>
</div>
</div>
<div class="sect2">
<h3 id="other-features"><a class="anchor" href="#other-features" />Other features</h3>
<div class="paragraph">
<p>Off course there’ll be other features introduced in CDI 2.0. They come from</p>
</div>
<div class="olist arabic">
<ol class="arabic">
<li>
<p>Standardization of existing extension like the ones created in <a href="http://deltaspike.apache.org/" target="_blank">Apache Deltaspike</a> project</p>
</li>
<li>
<p>Request from our <a href="http://www.cdi-spec.org/news/2014/05/28/CDI-2_0-survey/" target="_blank">CDI 2.0 survey</a> which will close on july 31st</p>
</li>
<li>
<p>Features coming from other Java EE 8 spec, like <code>@Transactional</code> was introduced in CDI 1.1 after it was extracted from EJB spec.</p>
</li>
</ol>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="next-step"><a class="anchor" href="#next-step" />Next Step</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The proposal is being discussed among JCP executive committee members and if everything goes well it should be accepted in the coming days. At this moment we’ll start forming the CDI 2.0 Expert Group and begin effective work around this specification.
We hope deliver the final spec in Q4 2015 or Q1 2016. Stay tuned on this blog or on <a href="http://twitter.com/cdispec">@cdispec</a> to have fresh news regarding the spec and the coming expert group.</p>
</div>
</div>
</div>
http://www.cdi-spec.org/news/2014/05/28/CDI-2_0-survey.htmlCDI 2.0 Survey2020-09-18T08:53:43+02:002014-05-28T00:00:00+00:00
Loading......
<iframe src="https://docs.google.com/forms/d/1R18nS65GshO46YCcksTTVILlAlgyk8PA5Vu7zJPDx2U/viewform?embedded=true" width="760" height="350" frameborder="0" marginheight="0" marginwidth="0">Loading...</iframe>
http://www.cdi-spec.org/news/2014/04/14/CDI-1_2-released.htmlCDI 1.2 released2020-09-18T08:53:43+02:002014-04-14T00:00:00+00:00
After one year of existence, the CDI 1.1 specification is updated by a maintenance release. This maintenance review known as CDI 1.2 was adopted by the JCP with 24 yes and one Expert Member forgetting to vote. The minor increment (from 1.1 to 1.2) instead of a 1.1-SP1 is due to the the fact that we changed the javadoc and the TCK but beyond that there are far less changes from 1.1 to 1.2 than from 1.0 to 1.1.
That’s being said, CDI 1.2 brings a lot of clarifications and small behavior changes. Let’s check what’s on the menu.
Major changes
Some of...
<div class="paragraph">
<p>After one year of existence, the CDI 1.1 specification is updated by a maintenance release. This maintenance review known as CDI 1.2 was adopted by the <a href="https://jcp.org/en/jsr/results?id=5623" target="_blank">JCP</a> with 24 yes and one Expert Member forgetting to vote. The minor increment (from 1.1 to 1.2) instead of a 1.1-SP1 is due to the the fact that we changed the javadoc and the TCK but beyond that there are far less changes from 1.1 to 1.2 than from 1.0 to 1.1.
That’s being said, CDI 1.2 brings a lot of clarifications and small behavior changes. Let’s check what’s on the menu.</p>
</div>
<div class="sect1">
<h2 id="major-changes"><a class="anchor" href="#major-changes" />Major changes</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Some of these changes are only big clarifications but some other have an impact on the implementations (these last ones have an asterisk in their title below). In order to use them you’ll have to grab a CDI 1.2 implementation (more info at the end of this post).</p>
</div>
<div class="sect2">
<h3 id="rethinking-the-default-bean-discovery-mode"><a class="anchor" href="#rethinking-the-default-bean-discovery-mode" />Rethinking the default bean discovery mode *</h3>
<div class="paragraph">
<p>The default bean discovery mode (<code>annotated</code>) that allows CDI to be activated by default in Java EE 7 without <code>beans.xml</code>, file was the root of a lot of issues with other frameworks implementing the AtInject specification (JSR-330) or with libraries thought to be used with such frameworks.
To solve these issues we changed the set of <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations" target="_blank">Bean defining annotations</a> (class annotations that make a class an implicit bean candidate) :</p>
</div>
<div class="ulist">
<ul>
<li>
<p>all pseudo scopes annotations except <code>@Dependent</code> were removed,</p>
</li>
<li>
<p><code>@Interceptor</code> and <code>@Decorator</code> were added,</p>
</li>
<li>
<p>all stereotype annotations (annotations annotated with <code>@Stereotype</code>) were added.</p>
</li>
</ul>
</div>
</div>
<div class="sect2">
<h3 id="clarification-of-conversation-resolution"><a class="anchor" href="#clarification-of-conversation-resolution" />Clarification of conversation resolution</h3>
<div class="paragraph">
<p>Conversation resolution mechanism could bring conflicts with servlet spec as stated in <a href="https://issues.jboss.org/browse/CDI-411" target="_blank">CDI-411</a>.</p>
</div>
<div class="paragraph">
<p>We clarified the fact that implementation should prevent these conflict during conversation resolution in <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec-diff.html#conversation_context" target="_blank">conversation context lifecycle</a></p>
</div>
</div>
<div class="sect2">
<h3 id="rework-on-event-chapter"><a class="anchor" href="#rework-on-event-chapter" />Rework on event chapter</h3>
<div class="paragraph">
<p>You think you know how event resolution works in CDI? If you gained this knowledge by a careful reading of chapter 10 of the specification, think again. This chapter had a lot of approximations and confusing mentions. It was reviewed and partly rewritten (and yes, <code>@Any</code> is totally useless for <code>Event<></code> injection, event firing and observers resolution).</p>
</div>
<div class="paragraph">
<p>This chapter is worth the <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events" target="_blank">re-reading</a>.</p>
</div>
<div class="paragraph">
<p>You can also check the <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec-diff.html#events" target="_blank">diff</a>, if you prefer.</p>
</div>
</div>
<div class="sect2">
<h3 id="beanmanager-more-permissive-during-initialization"><a class="anchor" href="#beanmanager-more-permissive-during-initialization" />BeanManager more permissive during initialization *</h3>
<div class="paragraph">
<p>In CDI 1.1, some BeanManager methods couldn’t be called before the <code>AfterDeploymentValidation</code> was fired. A non portable behavior was tolerated to allow use of these in <code>AfterBeanDiscovery</code> observers. These brought confusing mention in specification and javadoc. We decided to standardized the non portable behavior (not a big deal since all implementations adopted it). So in CDI 1.2 the following <code>BeanManager</code> method can be called (with restrictions) in an <code>AfterBeanDiscovery</code> observer method:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code>getBeans(String)</code>,</p>
</li>
<li>
<p><code>getBeans(Type, Annotation…)</code>,</p>
</li>
<li>
<p><code>getPassivationCapableBean(String)</code></p>
</li>
<li>
<p><code>resolve(Set)</code>,</p>
</li>
<li>
<p><code>resolveDecorators(Set, Annotation…)</code>,</p>
</li>
<li>
<p><code>resolveInterceptors(InterceptionType, Annotation…)</code>,</p>
</li>
<li>
<p><code>resolveObserverMethods(Object, Annotation…)</code>,</p>
</li>
<li>
<p><code>validate(InjectionPoint)</code>.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>more details on the <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec-diff.html#beanmanager" target="_blank">diff</a></p>
</div>
</div>
<div class="sect2">
<h3 id="clarification-on-container-lifecycle-event-use"><a class="anchor" href="#clarification-on-container-lifecycle-event-use" />Clarification on container lifecycle event use</h3>
<div class="paragraph">
<p>We clarified the fact these event should only be used during invocation of their observer methods.
Check the <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec-diff.html#init_events" target="_blank">diff</a> of the whole 11.5 paragraph</p>
</div>
</div>
<div class="sect2">
<h3 id="rework-on-the-initialization-phase-parts"><a class="anchor" href="#rework-on-the-initialization-phase-parts" />Rework on the initialization phase parts</h3>
<div class="paragraph">
<p>Description of initialization phase in chapter 11 & 12 was very messing. No chronological ordering of event fired by the container, missing events. For instance we forgot to speak with <code>ProcessInjectionPoint</code> and <code>ProcessBeanAttributes</code> and <code>ProcessProducer</code> was wrongly placed before <code>ProcessBean</code> in chapter 12.
So if you’re planning to write portable extensions you should perhaps re-read <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#http://docs.jboss.org/cdi/spec/1.2/cdi-spec-diff.html#packaging_deployment" target="_blank">chapter 12</a>. Not yet a page turner but far more accurate than it use to be.</p>
</div>
</div>
<div class="sect2">
<h3 id="cdi-api-now-officially-supporting-osgi"><a class="anchor" href="#cdi-api-now-officially-supporting-osgi" />CDI API now officially supporting OSGi</h3>
<div class="paragraph">
<p>We integrated all OSGi bundle information in CDI 1.2 api jar. So now it’ll be easier to use CDI in OSGi environment. Before that you had to grab a special OSGi release of CDI 1.1 to have the good bundle info in our <code>META-INF/MANIFEST.MF</code>.</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="more-minor-changes"><a class="anchor" href="#more-minor-changes" />More minor changes</h2>
<div class="sectionbody">
<div class="paragraph">
<p>You can check the <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#_major_changes" target="_blank">change section</a> of the spec to check the more minor changes we introduces in the spec.
We also work on Javadoc to synchronize it with the specification by updating it or correcting the spec when api description were wrong.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="concrete-stuff"><a class="anchor" href="#concrete-stuff" />Concrete stuff</h2>
<div class="sectionbody">
<div class="paragraph">
<p>You’ll find concrete raw and final data in the links below.</p>
</div>
<div class="ulist">
<ul>
<li>
<p>You’re interested by the release notes? it’s <a href="https://issues.jboss.org/secure/ReleaseNote.jspa?version=12323655&styleName=Html&projectId=12311062" target="_blank">here</a>.</p>
</li>
<li>
<p>You want to check the diff between CDI 1.1 spec and CDI 1.2 spec? You’ll find it <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec-diff.html" target="_blank">there</a></p>
</li>
<li>
<p>You can’t wait to read this new spec, the Javadoc or use with the API or TCK? Go to our <a href="http://www.cdi-spec.org/download" target="_blank">download page</a></p>
</li>
<li>
<p>You want to start coding in CDI 1.2? Good news reference implementation (Weld 2.2.0) is available and provide all that’s needed to be integrated to a Java EE 7 server. More information on <a href="http://weld.cdi-spec.org/news/2014/04/15/weld-220-final/" target="_blank">Weld 2.2.0 announcement</a></p>
</li>
</ul>
</div>
</div>
</div>
http://www.cdi-spec.org/news/2014/02/13/TCK-1_1_3-release.htmlCDI TCK 1.1.3.Final released2020-09-18T08:53:43+02:002014-02-13T00:00:00+00:00
We’ve just released CDI TCK 1.1.3.Final - the third bugfix version for CDI 1.1. The artifacts are available in the Maven central repository and the distribution zip file on sourceforge.net.
Note that the exclude list in the canonical TestNG config file is clean now.
See also the list of resolved issues:
Here...
<div class="paragraph">
<p>We’ve just released CDI TCK 1.1.3.Final - the third bugfix version for CDI 1.1. The artifacts are available in the Maven central repository and the distribution zip file on <a href="https://sourceforge.net/projects/jboss/files/CDI-TCK/1.1.3.Final/" target="_blank">sourceforge.net</a>.</p>
</div>
<div class="paragraph">
<p>Note that the exclude list in the canonical <a href="https://github.com/cdi-spec/cdi-tck/blob/1.1/impl/src/main/resources/tck-tests.xml">TestNG config file</a> is clean now.</p>
</div>
<div class="paragraph">
<p>See also the list of resolved issues:
<a href="https://issues.jboss.org/issues/?jql=fixVersion%20%3D%20%221.1.3.Final%22%20AND%20project%20%3D%20CDITCK" target="_blank">Here</a></p>
</div>
http://www.cdi-spec.org/news/2013/12/17/Make-3-CDI-2_0-wishes.htmlMake 3 CDI 2.0 Wishes2020-09-18T08:53:43+02:002013-12-17T00:00:00+00:00
Loading......
<iframe src="https://docs.google.com/forms/d/1AEQthlREvqd1fHMM5Ea8lyHfKiPlgiJS9omfnM8DLeQ/viewform?embedded=true" width="760" height="350" frameborder="0" marginheight="0" marginwidth="0">Loading...</iframe>
http://www.cdi-spec.org/news/2013/12/16/EG-meeting.htmlCDI EG meeting 12/16/2013 notes on CDI 1.22020-09-18T08:53:43+02:002013-12-16T00:00:00+00:00
The following people assisted this meeting :
Mark Struberg (ms)
Joseph Bergmark(jb)
Jozef Hartinger (jh)
Martin Kouba (mk)
JJ Snyder (jj)
Phil Zampino (pz)
Antoine Sabot-Durand (asd)
Proposed Agenda
The following agenda was proposed
Discussion on the last ticket pending : CDI-395 Public fields in extensions should not be allowed
Last second ticket
Next step for the MR.
Discussion on CDI-395
We were waiting on implementation feedback on this point. jh told us that there was too much risk to create retro-compatibility issues. So it was decided to remove CDI-395 from MR.
Last minute issues
Jira
Description
Decision
Note
CDI-408
bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
in MR
CDI-410
@RequestScoped Javadoc outdated
in MR
CDI-388
Session bean specialization example is not valid
in MR
CDI-376
BeanManager#getProducerFactory return type differs between...
<div class="paragraph">
<p>The following people assisted this meeting :</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Mark Struberg (ms)</p>
</li>
<li>
<p>Joseph Bergmark(jb)</p>
</li>
<li>
<p>Jozef Hartinger (jh)</p>
</li>
<li>
<p>Martin Kouba (mk)</p>
</li>
<li>
<p>JJ Snyder (jj)</p>
</li>
<li>
<p>Phil Zampino (pz)</p>
</li>
<li>
<p>Antoine Sabot-Durand (asd)</p>
</li>
</ul>
</div>
<div class="sect1">
<h2 id="proposed-agenda"><a class="anchor" href="#proposed-agenda" />Proposed Agenda</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The following agenda was proposed</p>
</div>
<div class="olist arabic">
<ol class="arabic">
<li>
<p>Discussion on the last ticket pending : CDI-395 Public fields in extensions should not be allowed</p>
</li>
<li>
<p>Last second ticket</p>
</li>
<li>
<p>Next step for the MR.</p>
</li>
</ol>
</div>
</div>
</div>
<div class="sect1">
<h2 id="discussion-on-cdi-395"><a class="anchor" href="#discussion-on-cdi-395" />Discussion on CDI-395</h2>
<div class="sectionbody">
<div class="paragraph">
<p>We were waiting on implementation feedback on this point. <strong>jh</strong> told us that there was too much risk to create retro-compatibility issues. So it was decided to remove CDI-395 from MR.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="last-minute-issues"><a class="anchor" href="#last-minute-issues" />Last minute issues</h2>
<div class="sectionbody">
<table class="tableblock frame-all grid-all spread">
<colgroup>
<col style="width: 8.3333%;">
<col style="width: 50%;">
<col style="width: 8.3333%;">
<col style="width: 33.3334%;">
</col>
<thead>
<tr>
<th class="tableblock halign-left valign-top">Jira</th>
<th class="tableblock halign-left valign-top">Description</th>
<th class="tableblock halign-left valign-top">Decision</th>
<th class="tableblock halign-left valign-top">Note</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-408" target="_blank">CDI-408</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-410" target="_blank">CDI-410</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">@RequestScoped Javadoc outdated</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-388" target="_blank">CDI-388</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Session bean specialization example is not valid</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-376" target="_blank">CDI-376</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">BeanManager#getProducerFactory return type differs between API and spec</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-411" target="_blank">CDI-411</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">CDI conversation activation conflicts with the Servlet spec</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Pending</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">needs some test before decicing if we can include it in MR. Test leaded by <strong>jh</strong></p></td>
</tr>
</tbody>
</col>
</col>
</col>
<div class="sect1">
<h2 id="next-step"><a class="anchor" href="#next-step" />Next Step</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The list is now closed (except for 411) It’s accessible <a href="../CDI-1-2-issues-list">here</a> and in <a href="http://s.shr.lc/1dL7BrF">Jira</a>.
The Maintenance Release will be officially launch on the 6th january week. By then, work and discussion can start on the ticket chosen for this MR.</p>
</div>
</div>
</div></colgroup></table></div></div>
http://www.cdi-spec.org/news/2013/12/16/CDI-1-2-issues-list.htmlConclusion of EG preparation on CDI 1.22020-09-18T08:53:43+02:002013-12-16T00:00:00+00:00
Updated on 01/07/2014
We finished to deal with the list of 28 Jira we planned to introduce or not in MR. So 24 of them will be in MR and 4 won’t. The list is also accessible on Jira.
Jira
Description
Decision
Note
CDI-413
Update outdated license
in MR
CDI-408
bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
in MR
CDI-410
@RequestScoped Javadoc outdated
in MR
CDI-388
Session bean specialization example is not valid
in MR
CDI-376
BeanManager#getProducerFactory return type differs between API and spec
in MR
CDI-377
automatic JSR-330 annotation processing problematic
in MR
Mention needed and perhaps a new feature
CDI-380
Clarify SessionScoped
in MR
We should be less descriptive and like for CDI-381 add a general statement telling that other spec/extensions can change the behavior of built-in...
<div class="paragraph">
<p><em>Updated on 01/07/2014</em></p>
</div>
<div class="paragraph">
<p>We finished to deal with the list of 28 Jira we planned to introduce or not in MR. So 24 of them will be in MR and 4 won’t. The list is also accessible on <a href="http://s.shr.lc/1dL7BrF">Jira</a>.</p>
</div>
<table class="tableblock frame-all grid-all spread">
<colgroup>
<col style="width: 8.3333%;">
<col style="width: 50%;">
<col style="width: 8.3333%;">
<col style="width: 33.3334%;">
</col>
<thead>
<tr>
<th class="tableblock halign-left valign-top">Jira</th>
<th class="tableblock halign-left valign-top">Description</th>
<th class="tableblock halign-left valign-top">Decision</th>
<th class="tableblock halign-left valign-top">Note</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-413" target="_blank">CDI-413</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Update outdated license</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-408" target="_blank">CDI-408</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-410" target="_blank">CDI-410</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">@RequestScoped Javadoc outdated</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-388" target="_blank">CDI-388</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Session bean specialization example is not valid</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-376" target="_blank">CDI-376</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">BeanManager#getProducerFactory return type differs between API and spec</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-377" target="_blank">CDI-377</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">automatic JSR-330 annotation processing problematic</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Mention needed and perhaps a new feature</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-380" target="_blank">CDI-380</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Clarify SessionScoped</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">We should be less descriptive and like for CDI-381 add a general statement telling that other spec/extensions can change the behavior of built-in scope</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-372" target="_blank">CDI-372</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">clarify behavior of implicit bean archive</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">The notion of Bean Archive is introduce in Chapter 12, we should do an introduction before</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-320" target="_blank">CDI-320</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Clarify whether ProcessAnnotatedType should be fired for annotations</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">According to pm it shouldn’t and we should clarify this</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-318" target="_blank">CDI-318</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">@WithAnnotations types can appear on any supertype</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Mainly Javadoc correction on @WithAnnotation</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-280" target="_blank">CDI-280</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">behavior of CDI bean @Specializes session bean is undefined</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">could benefit some clarification</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-220" target="_blank">CDI-220</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Clarify interceptors are not associated with the result of a producer method/field</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-405" target="_blank">CDI-405</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-401" target="_blank">CDI-401</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Clarify the meaning of "bean class local view"</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-398" target="_blank">CDI-398</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-392" target="_blank">CDI-392</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Clarify when the operations of BeanManager can be called</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-386" target="_blank">CDI-386</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Two examples in section 5.2.4 contradict the rules of the same section</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-382" target="_blank">CDI-382</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Clarify interceptors are not associated with the result of a producer method/field</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-381" target="_blank">CDI-381</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Additional implementations of Request Context</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">we should add general statement telling that extension can change the behavior of built-in scope</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-406" target="_blank">CDI-406</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Make stereotypes bean defining annotations</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-404" target="_blank">CDI-404</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated"</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top" />
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-389" target="_blank">CDI-389</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Revert <a href="https://issues.jboss.org/browse/CDI-85" target="_blank">CDI-85</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">we revert to CDI 1.0 behavior but we will have to propose something better in CDI 2.0</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-397" target="_blank">CDI-397</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Clarify Section 6.6.3 regarding singletons</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">we should go a little beyond and check all occurrences of "singleton" in the spec to clarify if it’s an singleton session bean or a singleton scope</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-411" target="_blank">CDI-411</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">CDI conversation activation conflicts with the Servlet spec</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">in MR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Solution exist at different level. We should at least put a mention in the spec and o something at impl level</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-379" target="_blank">CDI-379</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Clarify life cycle of RequestScoped</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">out MR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">each spec should detail how they stick to built-in scope</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-370" target="_blank">CDI-370</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Expand @RequestScoped and @SessionScoped to account for WebSocket</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">out MR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">It’s the responsibility of Websocket spec. We should ensure they take the point before closing the ticket</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-377" target="_blank">CDI-77</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">out MR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Container doesn’t have to support this : the ticket should be closed</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://issues.jboss.org/browse/CDI-395" target="_blank">CDI-395</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Public fields in extensions should not be allowed</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">out MR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">it can bring backwards compatibility problem to correct this issue. We should see if impls allows it today. If it’s not the case it could be safely added to the MR</p></td>
</tr>
</tbody>
</col></col></col></colgroup></table>