Weld 3.0.0.Alpha15

2016-2-4   release , cdi2   Martin Kouba

Weld 3.0.0.Alpha15 the next experimental Weld version has been released. See also the release details.

The CompletionStage used to bind actions to the completion of the asynchronous delivery is now using org.jboss.weld.manager.api.ExecutorServices SPI as the default asynchronous execution facility. Previously, the ForkJoinPool#commonPool() (a default executor of the underlying CompletableFuture) was used. It’s an important change because the ForkJoinPool#commonPool() is not a good fit for Java EE. See also WELD-2073.

The ExperimentalAfterBeanDiscovery receives two more methods: interceptorBuilder() and addInterceptor(). An interceptor builder allows you to create an interceptor bean without the need to create an interceptor class. This might be handy for simple use cases:

class MyExtension {
      void afterBeanDiscovery(@Observes AfterBeanDiscovery event) {
        event.addInterceptor().intercept(InterceptionType.AROUND_INVOKE, (c) -> {
                long start = System.currentTimeMillis();
                try {
                    return c.proceed();
                } finally {
                    System.out.println("Time: " + System.currentTimeMillis() - start);

See also WELD-2008.

This release also contains some enhancements and bugfixes around proxies. E.g. better support for DeltaSpike partial beans (WELD-2084), better support for Camel CDI (WELD-2089) and better support for proxies with non public classes (WELD-2091). Furthermore, we are going to drop Jetty 7,8, 9.0, 9.1 and 9.2 support in Weld 3 (WELD-2032). Also the decorator validation was improved (WELD-2085, WELD-1811, WELD-2039). Last but not least, we have performed some SPI cleanup (WELD-2077, WELD-2079).

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.Final. If you’re not familiar with patching WildFly, check Markus’s tutorial.

Weld 2.3.2.Final

2015-12-10   release   Martin Kouba

Weld 2.3.2.Final the last version for this year has been released! It is a bug-fixing release with 15 issues resolved. See also the release details. Thanks to everyone involved in this release!

Notable bug-fixes and enhancements

  • Weld proxies - add workaround for IBM JVM 8 (WELD-2056 and DELTASPIKE-1010)

  • Fix resource injection when using arquillian-weld-ee-embedded-1.1 (WELD-2065 and ARQ-2000)

  • All conversation contexts should be destroyed after the Servlet.service() method completes (WELD-2052)

  • Clear RequestScopedCache for remote EJB calls (WELD-2069)

  • Weld Servlet

    • Allow to perform dependency injection upon objects not having a CDI-compatible constructor (WELD-2039)

    • Add Jandex support even for WARs not extracted to the file system (WELD-2070)

  • Probe development tool is now part of the OSGi bundle (WELD-2061)

Weld 3.0.0.Alpha14

2015-12-4   release , cdi2   Martin Kouba

Weld 3.0.0.Alpha14 the penultimate Weld version for this year has been released into the wild. It reflects some of the most recent changes in the CDI 2.0 specification, mostly related to asynchronous events. Moreover, this release also contains quite a lot of enhancements and bugfixes. See also the release details.

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.CR4. If you’re not familiar with patching WildFly, check Markus’s tutorial.

Arquillian container SE 1.0.0.CR1 released!

2015-11-25   arquillian , testing   Tomas Remes

We are pleased to announce a new release of Arquillian container SE. If you are looking for a reliable way to test your application in Java SE then this is the right tool to try out!

This managed SE container launches new JVM process for each of your test archives. This standalone process with isolated classpath is also the main reason why we introduced such tool (and also the difference e.g to arquillian-weld-se-embedded).

You can manage your classpath dependencies by using ShrinkWrap resolver. Another option is to provide path to your directory containing your dependencies jars via container property. You can get ready your dependencies jars by using e.g Maven dependency plugin. Another options which you would expect as debugging, setting system properties or exporting deployment archive are also available. Test execution is managed by Arquillian JMX protocol.

Finally you can find some basic tests using Arquillian container SE in Weld SE tests or in CDI TCK. Feedback is more than welcomed and if you have any questions don’t hesitate to ask!

Maven Coordinates:

Weld development mode and JMX support

2015-11-10   probe , jmx   Martin Kouba

Weld comes with a special mode for application development. When enabled, some interesting data are collected so that it’s possible to inspect and monitor application components at runtime. Data in JSON format are available through the REST API, eventually through the MXBean of name org.jboss.weld.probe:type=JsonData,context=ID where ID should be replaced with an identifier of an application. The JMX support might be especially useful for environments and applications which do not utilize a web container (Java SE, OSGi, etc.).

How to enable JMX support

Simply use the Weld configuration facility and org.jboss.weld.probe.jmxSupport configuration property. If set to true one or more MBean components may be registered so that it is possible to use JMX to access the Probe development tool data.

JMX client

So for example if using Weld SE without a web container it’s still possible to access the Probe data. There is a lot of JMX clients out there (for example jconsole or jvisualvm from the Oracle JDK). The problem is not all of us prefer reading JSON data. Hey wait! Weld Probe already has an HTML client, right? Yes, but this client works with REST API. We would have to embed a web container (e.g. Undertow) and add Weld Servlet or do some configuration manually. But what if there are multiple Weld instances in the same JVM? The configuration might become quite complex. Luckily, there is another solution - a working prototype of JMX client reusing the default HTML GUI.

Clone, build and run

    # Clone the git repo
        git clone
        # Specify the weld version used in your application and run the build
        mvn clean package -Dversion.weld=2.3.1.Final
        # Run the client
        java -jar target/weld-probe-jmx-1.0.0-SNAPSHOT-shaded.jar

How does it work?

  • First, the client attempts to connect to a JMX server (your application)

  • User may select a Weld container to inspect

  • Then the client starts an Undertow instance locally, HTML client is available at:

  • Data are fetched remotely through JMX

  • User may reconnect at any time

See also the JBoss Forge example below to see an example output.


Moreover, it’s also possible to configure the JMX server URL, Undertow host and port - used to expose the HTML client. E.g. for WildFly (standalone mode) a different jmxServiceUrl must be specified and jboss-client.jar must be also on the class path, e.g.:

java -Dorg.jboss.weld.probe.jmxServiceUrl="service:jmx:http-remoting-jmx://" -cp '/opt/jboss/wildfly/bin/client/jboss-client.jar:target/weld-probe-jmx-1.0.0-SNAPSHOT-shaded.jar' org.jboss.weld.probe.ProbeJmx

JBoss Forge example

An interesting use case would be to inspect JBoss Forge addons powered by CDI (works with Forge 2.20.1.Final and later). Before we start Forge we need to set some extra system properties:

export FORGE_OPTS="-Dorg.jboss.weld.development=true -Dorg.jboss.weld.probe.jmxSupport=true -Dorg.jboss.weld.probe.eventMonitor.containerLifecycleEvents=true"

System properties starting with simply allow to connect to JMX remotely. org.jboss.weld.development enables the development mode. org.jboss.weld.probe.jmxSupport enables the JMX support. Finally, If org.jboss.weld.probe.eventMonitor.containerLifecycleEvents is set to true all the container lifecycle events are monitored during bootstrap.

Then start the Forge as usually and run the prototype. You should see a similar output:

Connecting to a remote JMX server: service:jmx:rmi:///jndi/rmi://
    Select a Weld container (JSON data provider):
    [0] org.jboss.weld.probe:type=JsonData,context="org.jboss.forge.addon:shell_1447145001728"
    [1] org.jboss.weld.probe:type=JsonData,context="org.jboss.forge.addon:configuration_1447145001592"
    [2] org.jboss.weld.probe:type=JsonData,context="org.jboss.forge.addon:parser-java_1447145002037"
    [3] org.jboss.weld.probe:type=JsonData,context="org.jboss.forge.addon:bean-validation_1447145001526"
    [4] org.jboss.weld.probe:type=JsonData,context="org.jboss.forge.addon:javaee_1447145003135"
    [5] org.jboss.weld.probe:type=JsonData,context="org.jboss.forge.addon:ui_1447145001709"
    [6] org.jboss.weld.probe:type=JsonData,context="org.jboss.forge.addon:convert_1447145001526"

Now select a Weld container to inspect, e.g. 5:

[disconnected]$ 5
    Connecting to the Weld container [5]: org.jboss.weld.probe:type=JsonData,context="org.jboss.forge.addon:ui_1447145001709"
    Starting Undertow...
    Lis 10, 2015 9:44:16 DOP. org.xnio.Xnio <clinit>
    INFO: XNIO version 3.3.1.Final
    Lis 10, 2015 9:44:16 DOP. org.xnio.nio.NioXnio <clinit>
    INFO: XNIO NIO Implementation Version 3.3.1.Final
    Weld Probe HTML client available at:
    [connected #5]$

The HTML client is available at It’s also possible to reconnect or exit. Type help to get a list of all possible commands.