Weld 2.3.0.Final released!

2015-9-18: Martin Kouba

Weld 2.3.0.Final has been just released! From now on, 2.3 is the current stable version of Weld and 2.2 is not actively developed anymore - i.e. no new features are added, only bugs will be fixed. Weld 2.3 will remain a CDI 1.2 implementation. We are incrementing the minor version due to several new features added. Weld 2.3 is also included in WildFly 10 application server.

Notable features and changes:

  • Java 6 support was dropped - Java 7 is the minimal requirement for building and running Weld 2.3

  • Weld 2.3 comes with a special mode for application development, the Probe development tool allows to inspect application CDI components at runtime

  • Weld SE Bootstrap API was enhanced in many ways - new features are mostly backported from Weld 3 development branch

  • Weld Servlet now supports Undertow web server

  • Revised delivery of @Initialized/@Destroyed events for @ApplicationScoped in an EAR (see also WELD-1821)

Weld 2.2.16.SP1

In addition, Weld 2.2.16.SP1 has been also released. It’s a bugfix release for 2.2 branch.

JDK 8u60 reveals a problem in Weld

2015-9-15: Martin Kouba

Recently released JDK 8u60 has revealed a problem in Weld where not all synthetic members were ignored correctly. This has been fixed in 2.2.16.Final, 2.3.0.CR2 and 3.0.0.Alpha14 (not released yet). However, if not using a lambda referencing an event/disposed parameter inside an observer/disposer method, your application is most probably not affected. See also the related issue - WELD-2019.

Use case

If there is a lambda referencing an event/disposed parameter inside an observer/disposer method, the compiler creates a synthetic method with the event parameter as one of the method parameters. Since 8u60 the parameter annotations are preserved even for the synthetic method. And so Weld incorrectly recognizes these synthetic methods as observer/disposer methods.


You may get WELD-000409: Observer method for container lifecycle event can only…​ if using such a lambda in an extension or even WELD-001408 Unsatisfied dependencies for type…​ if using such a lambda in a regular observer and the lambda is using more references (i.e. not only event/disposed parameter) - these are also the method parameters of the synthetic method, and in CDI these additional parameters are injection points.


class Foo {
      void observe(@Observes @Juicy String payload) {
        Arrays.asList("foo").stream().filter((s) -> s.equals(payload));

A synthetic method is created for the lambda and the event parameter is passed as a method parameter. The annotations are preserved. As a result Weld creates two observer methods having the same event parameter: @Observes @Juicy String payload.


Instead of the event parameter reference use an additional local variable with the same value assigned:

public void observe(@Observes @Juicy String payload) {
       String p = payload;
       Arrays.asList("foo").stream().filter((s) -> s.equals(p));

Weld team changes

2015-9-8: Jozef Hartinger

I am pleased to announce a couple of changes coming to the Weld team:

First of all, Martin will be taking over leadership of the project. Martin has proven himself to be an excellent engineer over all the years and I am happy that I can leave the project in his hands. His primary task is going to be leading the project towards the Weld 3 milestone.

Secondly, I will be moving to work temporarily on a different project. I truly enjoyed working on Weld and with the CDI community. Now after almost 4 years on the project I was given an exciting opportunity which I decided to pursuit.

Last but not least, Matěj Novotný is joining the team as a quality engineer. He’s going to work on expanding our testsuites and making sure Weld releases do not break anything :-)

Weld 3.0.0.Alpha12 - CDI 2.0 EDR1 Reference Implementation!

2015-8-5: Martin Kouba

Weld 3.0.0.Alpha12 has been released. Compared to previous alpha releases this is an important milestone - it’s a reference implementation of CDI 2.0 Early Draft (EDR1). You can read more about CDI 2.0 EDR1 on the official blog: CDI 2.0 Early Draft Review 1 released.

Bootstrapping a CDI container in Java SE

Starting a CDI container is now really that easy:

public static void main(String... args) {
        try(CDI<Object> cdi = CDI.getCDIProvider().initialize()) {
            ComputingService service = cdi.select(ComputingService.class).get();

javax.enterprise.inject.spi.CDI now implements AutoCloseable and can therefore be used in a try-with-resources block.

Note that the specification of the bean discovery process in Java SE is not finished yet. Therefore, bean archives which don’t contain a beans.xml file are not supported. The main reason is that we don’t want to implement a feature which is being discussed and will likely undergo some important changes. Nevertheless, the feature will be implemented in one of the next alpha versions.

Weld SE bootstrap API

How does it compare to Weld SE bootstrap API? Weld has provided support for the Java SE environment for a long time. Recently, the org.jboss.weld.environment.se.Weld class was turned into a powerful builder which allows to configure the Weld container before it is initialized.

Typical usage of the Weld SE API looks like this:

try (WeldContainer container = new Weld().initialize()) {
        ComputingService service = container.select(ComputingService.class).get();

This looks very similar to CDI SE, right? However, there are several advanced feratures available:

  • automatic scanning can be disabled, classes or packages can be selected explicitly

    • WeldContainer container = new Weld().disableDiscovery().beanClasses(Foo.class, Bar.class).alternatives(Bar.class).interceptors(FooInterceptor.class).initialize();

  • WeldContainer allows to fire events easily

    • container.event().select(Bar.class).fire(new Bar());

  • Weld-specific configuration options can be specified using the builder

  • it is possible to start multiple independent Weld instances (specification does not require this)

See also Weld 3.0.0.Alpha8 announcement for more information.

Asynchronous Events

An experimental support of asynchronous events is implemented in Weld since 3.0.0.Alpha3. However, in this release the API was aligned with CDI 2.0 EDR1:

class OrderProcessor {
        @Inject Event<Order> orderEvent;
        public void process(Order order) {
            orderEvent.fireAsync(order).thenAccept((o)->System.out.println("Asynchronous processing finished: " + o.getId()));
        public void processingOrder(@Observes Order event) {
            // This observer is notified synchronously, before the fireAsync() method returns
        public void asyncProcessingOrder(@ObservesAsync Order event) {
            // This observer is notified asynchronously, in a different thread

There are few important things to notice:

  • the event was triggered with fireAsync()

  • the asynchronous observer is defined by @ObservesAsync

  • synchronous observers defined by @Observes are also notified!

To sum it up:

Event method @Observes notified @ObservesAsync notified


yes, in the same thread



yes, in the same thread

yes, in a different thread

Observers SPI Changes

javax.enterprise.inject.spi.ObserverMethod now extends javax.enterprise.inject.spi.Prioritized and overrides the ObserverMethod.getPriority() method which is used to determine the notification order in which the event observer methods are invoked. Prioritized interface is currently only used for observers. However, the Weld team is working on a prototype where Prioritized can be used to globally select/enable custom alternative beans, interceptors and decorators, see also WELD-2000.

Furthermore, ObserverMethod.isAsync() method was added to determine whether an observer method is asynchronous or not.

WildFly Patch

As usual, a patch for WildFly is available. This patch not only upgrades Weld within an existing WildFly instance but also upgrades CDI API to 2.0 EDR1. This time the target platform is WildFly 10.0.0.Alpha6. If you’re not familiar with patching WildFly, check Markus’s tutorial.

Weld 3.0.0.Alpha8

2015-4-21: Jozef Hartinger

Weld 3.0.0.Alpha8 has been released. The main change is the enhanced API for using Weld in Java SE environment. In addition, this release comes with several weld-probe improvements.

Enhanced API for Weld SE

Weld has provided support for the Java SE environment for a long time with the weld-se module. The API provides an easy way for an application to initialize Weld and use it in a standalone mode. On initialization Weld SE scans the classpath for bean archives with the beans.xml file, similarly to how it’s done in the Java EE environment.

In this release we are extending the API further. This is partially inspired by the current discussion in the CDI expert group where a standardized CDI API for Java SE is being proposed as part of CDI-26.

The following code snippet shows the new API in action:

Weld builder = new Weld()
        .packages(Main.class, Utils.class)
        .property("org.jboss.weld.construction.relaxed", true);
    try (WeldContainer weld = builder.initialize()) {
        MyBean bean = weld.select(MyBean.class).get();

There are several new things to notice:

  • the Weld class is used as a builder to configure Weld before it is initialized

  • automatic scanning can be disabled

  • instead of scanning, classes or packages can be selected explicitly. All classes in those packages will be managed by Weld

  • interceptors, decorators, extensions and Weld-specific configuration options can be specified using the builder

  • WeldContainer now implements AutoCloseable and can therefore be used in a try-with-resources block. At any time that execution gets outside of the code block, the Weld instance is shut down and all managed instances are safely destroyed.

It is also possible to start multiple independent Weld instances:

new Weld().disableDiscovery().containerId("one").beanClasses(MyBean.class).initialize();
    new Weld().disableDiscovery().containerId("two").beanClasses(OtherBean.class).initialize();
    MyBean bean = WeldContainer.instance("one").select(MyBean.class).get();

Here, two independent WeldContainer instances are initialized. Each of them is given a unique ID. The ID can subsequently be used to obtain a WeldContainer reference in a different place of the code. One possible use-case this enables is for a library or framework (e.g. a testing framework) to use an embedded instance of Weld internally for its own needs (dependency injection, events, extensibility). This instance would not interfere with the Weld instance used by the application.

Obviously, automatic classpath scanning can still be used as before:

try (WeldContainer weld = new Weld().enableDiscovery().initialize()) {
        MyBean bean = weld.select(MyBean.class).get();


To play with the new API use the following dependency in you Maven project:


Aforementioned classes are from the org.jboss.weld.environment.se package.

Weld Probe Enhancements

Since the last Alpha releases there were several enhancements to Weld Probe. If you are not familiar with Weld Probe, check this introductory blog post first.

A new feature of Probe is that, when the development mode is enabled, it now embeds a tiny information bar directly into the application’s HTML output. That makes it easy to navigate to Probe directly from the application anytime. Furthermore, if invocation tracking is enabled, the information bar helps navigate directly to the invocation tree related to the request that rendered the output.

Weld Probe information bar embedded in application's HTML output

Additionally, the following Probe improvements were implemented:

  • tracked invocations are now grouped into a invocation tree instead of being tracked in isolation

  • a special type of edges is now used in the overview graph to represent a "declared by" relation (when a bean declares a producer method or field)

  • Instance<?> injection points are now treated specially - a resolved bean is show as injection point’s dependency

See this live demo and try Weld Probe yourself.

[ Experimental API documentation ] [ Release notes ] [ Distribution ] [ Patch for Wildfly (8.2, 9 Beta) ]