Weld 3.0.0.Alpha1 released!

2014-10-2   Jozef Hartinger

Today we are releasing Weld 3.0.0.Alpha1. This release serves as an early proof of concept of some of the ideas that are being discussed by the CDI Expert Group for the upcoming CDI 2.0 specification. Furthermore, this is a great opportunity for the community to test-drive some of the proposed improvements and provide us with feedback. Be warned though that this released does not come with any guarantee of stability and that binary and functional compatibility is likely to be broken in the following releases.

Ordering of observer methods

The first of the new features are ordered observer methods. This requirement came up a long ago and several approaches were proposed in the meantime, as documented by CDI-4.The Alpha1 release employs the general-purpose @Priority annotation to determine the order in which observer methods are to be notified.

There are many open questions about this feature. Here are some of the rules we set for the purpose of this experimental implementation. These are by no means set in stone but instead we encourage you to give us feedback on these:

  • Each observer method has a certain priority value. An observer method that does not define a priority explicitly is given the default priority which is 2500 (in the middle of the Interceptor.Priority.APPLICATION range)

  • The priority of an observer method determines the order. An observer method with lower value is called before an observer method with higher value

  • If multiple observer methods define the same priority value, the order is undefined

  • Observer methods priorities should match existing priority range convention

  • The ordering applies to both transactional and non-transactional observer methods

  • The priority annotation is applied on the event parameter (not the observer method)

Here’s an example:

public void sendWelcome(@Observes @Priority(APPLICATION + 800) @Registered User user) {
        // ...

Note that javax.annotation.Priority can currently only be applied to types. Therefore, we temporarily created a substitute called org.jboss.weld.experimental.Priority which is identical to the original except that it can also be applied on parameters (of observer methods). The plan is to propagate this change back to javax.annotation.Priority. In the meantime, Weld’s twin gets the job done.

In addition to the @Priority annotation, the SPI was also enhanced to expose the priority of an observer method. We are not touching javax.enterprise interfaces just yet. Instead, the org.jboss.weld.experimental package contains proposals for how the new SPI should look like. As the package name suggests, this SPI is good for a test-drive but do not expect it to be stable. To use the experimental SPIs, you’ll need to add a dependency on weld-api.

Here’s an example of reading the observer method priority using the SPI in an Extension. ExperimentalProcessObserverMethod and ExperimentalObserverMethod interfaces come from the org.jboss.weld.experimental package.

public class SimpleExtension implements Extension {
        void observe(@Observes ExperimentalProcessObserverMethod<User, ?> event) {
            ExperimentalObserverMethod<User> observerMethod = event.getObserverMethod();
            this.priority = observerMethod.getPriority();

Use the corresponding CDI ticket for any feedback on these features.

Vetoing and modifying observer methods

We’ll stay with observer methods for a few more paragraphs. A request was raised in the CDI issue tracker for making it possible to disable an observer method using the ProcessObserverMethod SPI.

This Alpha1 release introduces the veto() methods (aligned with ProcessAnnotatedType.veto()) for this:

void disableDebuggingObservers(@Observes ExperimentalProcessObserverMethod<?, Debug> event) {
        if (projectStage != ProjectStage.Development) {

In addition, the observer method metadata may be altered by an extension. This is done similarly to how InjectionTarget, InjectionPoint or BeanAttribute metadata are modified which is most often by wrapping the original object (decorator design pattern). Any piece of metadata (including aforementioned priority) can be altered. For example, the transaction phase:

void alterObserver(@Observes ExperimentalProcessObserverMethod<User, ?> event) {
        event.setObserverMethod(new ForwardingExperimentalObserverMethod<User>(event.getObserverMethod()) {
            public TransactionPhase getTransactionPhase() {
                return TransactionPhase.AFTER_SUCCESS;

Repeatable qualifiers and interceptor bindings

This release serves as a proof of concept for supporting repeating qualifiers and interceptor bindings. You can now fully utilize Java 8 features and use multiple qualifiers or interceptor bindings of the same type in the same location, for example:

public class School {
        public Student graduate() {
            // ...

Repeating qualifiers can be used for both bean and event resolution. See the Java documentation for how to define a repeating annotation.

Interceptor bindings in invocation context

This is an often recurring scenario. An interceptor binding defines several @NonBinding members which serve as configuration for the interceptor. How does an interceptor get hold of these values? This is not easy as the interceptor binding may often appear on the intercepted method, the class that defined it or may be inherited from another interceptor binding or stereotype (even transitively!). This problem gave birth to utilities such as this one. Still, even after all this effort the result is not entirely correct as it was obtained using Java reflection ignoring the fact that the interceptor binding may have been modified (e.g. using ProcessAnnotatedType).

This problem is being addressed as CDI-468. The Alpha1 release of Weld implements this feature and exposes new methods for obtaining interceptor bindings that are in effect for the interception. This is done using ExperimentalInvocationContext.getInterceptorBindings() or ExperimentalInvocationContext.getInterceptorBindingsByType().

Again, ExperimentalInvocationContext can be found in the org.jboss.weld.experimental package and depicts how the future version of javax.interceptor.InvocationContext could look like.

    public class SecurityInterceptor {
        private User user;
        public Object intercept(ExperimentalInvocationContext ctx) throws Exception {
            Secure binding = ctx.getInterceptorBindingsByType(Secure.class).iterator().next();
            if (!user.getRoles().contains(binding.requireRole())) {
                throw new SecurityException();
            return ctx.proceed();

Again, your feedback is welcome at CDI-468.

Changes in the Annotated layer

CDI provides an abstraction over the Reflection API - AnnotatedType and friends - which mostly allows extensions to alter the set of annotations present on a type, field, method, etc.

The Alpha1 release contains two minor additions to this API. Firstly, the API now supports Java 8 repeating annotations with a new method ExperimentalAnnotated.getAnnotationsByType(Class<T> annotationClass)

Secondly, it is now possible to access the java.lang.reflect.Parameter instance that is wrapped by AnnotatedParameter using ExperimentalAnnotatedParameter.getJavaParameter();

See CDI-471 and CDI-481 for details.


2014-9-18   Jozef Hartinger

Today, we released Weld 2.2.5.Final. The fifth mostly bug-fixing release in the series addresses 23 issues. In addition, the Servlet module got an update and among other things now supports:

  • all three bean discovery modes (e.g. only explicitly annotated classes will be loaded as CDI beans)

  • bean archive isolation

  • using Jandex for faster deployment discovery

See the reference documentation for details.

Talking about documentation we are grateful to Antoine Sabot-Durand for migrating our reference documentation to AsciiDoc. We also thank our community contributors Antonin Stefanutti and Stefan Grossmann who contributed with pull requests.

Weld 3.0

In the coming months, our focus will be shifting towards Weld 3.0 - the future reference implementation of CDI 2.0. Initially, we plan on releasing Alpha releases every two weeks starting in early October.

The Alpha releases are likely to break compatibility from time to time and will often contain bleeding edge or prototype code. The goals is however to give the CDI community a chance to test drive the proposed changes in the CDI specification as soon as possible and give quick feedback to the CDI expert group.

Weld 3.0 will also be a good opportunity to get involved in the development of this open-source project. Interested? See our community web page for more details.

Weld 2.2 (CDI 1.2 reference implementation) released!

2014-4-15   Jozef Hartinger

Today we released Weld 2.2.0.Final - the reference implementation of Contexts and Dependency Injection for Java EE 1.2 (CDI 1.2). Besides implementing the changes in the specification, this release comes with several new features, performance improvements and more than 50 bug fixes.

CDI 1.2

CDI 1.2 is a maintenance release of the CDI specification. It contains a number of small fixes and clarifications as well as several enhancements. Most notable changes for application developers are related to the definition of bean defining annotations.

In CDI 1.2, the set of bean defining annotations now contains:

  • all the normal scope annotations (e.g. @RequestScoped, @ApplicationScoped, …​)

  • the built-in @Dependent scope

  • @Interceptor and @Decorator annotations

  • stereotype annotations

As a result, any class annotated with a bean defining annotation is by default recognized by the application server and registered as a CDI bean. The beans.xml file is optional.

In addition, there are other fixes, clarifications and minor enhancements in this maintenance release of the CDI specification. See the release notes for the complete list of changes.


Weld is now capable of using bytecode-scanning utilities, such as the Jandex tool, to speed up deployment. This is especially notable in extra large deployments (e.g. 5000+ classes) where we observed up to 20% faster deployment.

In addition, there are noticeable improvements in the following areas:

  • runtime performance of observers, interceptors and decorators

  • session replication overhead (failover)

  • memory consumption

Weld 2.2 on WildFly

WildFly does not come with Weld 2.2 support yet. It is however easy to patch an existing WildFly installation to use Weld 2.2.

To do so, follow these steps:

  1. Download a patch appropriate for the WildFly version (e.g. 8.0.0.Final) from the download section

  2. In the WildFly installation, run the CLI console

  3. From the console run the following command:

    patch apply /path/to/

Your installation is now patched!

Weld SE and Servlet

Weld comes with the SE module which allows CDI to be used in plain Java SE environment. In Weld 2.2 we added partial support for implicit bean archives. Partial support here means that the beans.xml file is still required, but bean-discovery-mode=”annotated” can be specified for Weld to only discover classes explicitly annotated with bean defining annotations (see above).

In addition to the Weld SE module, Weld also provides the Weld Servlet module which makes it possible to use Weld on top of a plain Servlet container, such as Apache Tomcat or Jetty.

In this release we simplified configuration by bootstrapping Weld using the ServletContainerInitializer.

Furthermore, Weld Servlet now supports Jetty 9.1. At the same time, the support for Tomcat 6 was dropped. To summarize, Weld Servlet is currently supported on the following Servlet containers:

  • Tomcat 7, 8

  • Jetty 7, 8, 9.0, 9.1


We greatly appreciate your contributions to this release. Big thanks go to: Martin Kouba, Matúš Abaffy, Matej Briškár, Ron Šmeral, Marek Schmidt, Marko Lukša, Tomáš Remeš, Stuart Douglas, Radoslav Husár, Max Pimm, Alexandre Gattiker, Antonin Stefanutti and Steve Moyer.

CDI 1.2 and Weld 2.2

2014-2-4   Jozef Hartinger

Work on a maintenance release of the CDI specification (CDI 1.2) has started recently. Now is the best time to add feedback on issues being addressed. Most of the discussion happens in the cdi-dev mailing list or the IRC channel.

Weld 2.2 is going to be the reference implementation of CDI 1.2. Besides implementing the changes introduced in the maintenance release, we are going to focus on improving non-functional characteristics in this release of Weld:

  • bootstrap time

  • memory footprint

  • throughput

  • maximum number of concurrent clients

  • session replication overhead

Today, we released Weld 2.2.0.Alpha1. The most significant changes include:

  • Added new SPI that allows bytecode-scanning frameworks (such as jandex) to be integrated. This yields improved bootstrap time especially with large deployments.

  • Reduced memory consumption (our tests show 6-12% less memory used after bootstrap with large deployments)

  • Improved event/observer performance

  • Java Web Start support finally got in (thanks to Alexandre Gattiker for the patch!)

  • Improved Servlet container support (Jetty 9.1, ServletContainerInitializer used to bootstrap Weld, Tomcat 8 support)

  • A new Groovy example (groovy-numberguess) was added

  • Many other bug fixes and improvements. See the release notes for a complete list of changes

Now, we continue to work on Weld 2.2. Expect the final version in late March. In the meantime, try this release and let us know what you think in the forum. If you are interested in Weld make sure you check our community page or the list of open issues awaiting contribution.

Three new Weld releases

2014-1-14   Jozef Hartinger

This week we are releasing three new builds of Weld. Firstly, Weld 2.1.2.Final was released. This is a bug-fixing release with 11 issues resolved. Most notably:

  • The conversation context is now initialized lazily. This resolves the problem with custom character encoding that many of you run into. See the reference documentation for details.

  • Weld now runs fine on JDK8

  • Jetty 9.1 is now supported by weld-servlet

In addition, Weld 1.1.17.Final (CDI 1.0) was released with several bug fixes.

Last but not least, there was a memory leak identified in GlassFish caused partly by GlassFish and partly by Weld. GlassFish still uses Weld 2.0. Although we do not maintain the 2.0 branch any longer and advice everyone to upgrade to Weld 2.1, the memory leak may be a problem for GlassFish users that are not able to upgrade to Weld 2.1 themselves. Therefore, we decided to do one more 2.0 release where this problem is fixed so that GlassFish users stuck on Weld 2.0 have an easy fix. Enjoy Weld 2.0.5.Final!

Now, our focus shifts completely towards Weld 2.2 where performance optimization and lowering memory consumption are the main goals. Expect first Alpha of Weld 2.2 by the end of January.

If you are interested in Weld make sure you check our community page or the list of open issues awaiting contribution.