Weld 2.4.5.Final

2017-9-11   release   Matej Novotny

It’s about time we delivered another regular bugfix release for Weld 2. And while the list of fixes isn’t exhausting, some of them are quite crucial.

Notable fixes and improvements:

  • Weld Core:

    • Revise Java 8 default methods plus proxies/sublasing behaviour (WELD-2407 and WELD-2405)

    • All POMs in Weld core project should now have correct MIME types; this corrects issues with Nexus 3 (WELD-2417)

    • Proxies for signed packages should now be generated in custom packages (WELD-2402)

    • The behaviour of Weld Core and integrator provided implementation of org.jboss.weld.bootstrap.api.Environment is back to what it was in Weld 2.4.3.Final (WELD-2401)

      • We found out this change could cause serious headaches to integrators so we will leave it as it is - sorry for the mess

      • For Weld 3, we already have a better solution in place

  • Weld SE and Servlet

    • Both, Weld SE and Weld Servlet, will now explicitly bring in dependency on jboss-classfilewriter 1.2+ (WELD-2406)

  • Other

    • Under the jboss-as directory of Weld source code, you can now make use of new profiles to create WildFly patches yourself WELD-2397

WildFly Patch

As usual, a patch for WildFly 10.1.0.Final is available. But since WildFly 11 has already reached CR stage, we have decided to also provide you with patch for WildFly 11.0.0.CR1. If you’re not familiar with patching WildFly, check the FAQ.

Weld 3.0.1.Final

2017-8-25   release   Matej Novotny

Weld 3.0.1.Final is out and it brings some bugfixes as well as new version of Weld API - 3.0.SP1. Among the new things you can find sweet stuff such as an expansion to CDI 2 BeanConfigurator API or the ability to detect that injected object is Weld proxy. Wait, not only detect - you can also use it do get Metadata or even retrieve the actual contextual instance hidden beneath. So let’s see the summary of fixes and improvements, shall we?

Notable fixes and improvements:

  • Weld Core

    • Revised support for Java 8 default methods (WELD-2407 and WELD-2405)

    • Corrected MIME types for all POMs in Weld core - Nexus 3 will love us now! (WELD-2417)

    • Fixed how proxies are created for signed packages (WELD-2402)

    • Portable extension events should now be fired in accordance with specification WELD-2393

  • Weld SE

    • Synthetic bean archive can now have discovery mode annotated (WELD-2386)

    • Added a convenient static method WeldContainer.current() allowing you to quickly grab your running instance (WELD-2399)

    • Fixed a glitch when starting SE container and adding packages via Weld.addPackages() WELD-2395

  • Weld API/SPI

    • Added a way to detect proxies and subclasses (WELD-2407)

      • Every Weld-enhanced object (subclass/proxy) will now implement new marker interface(s) which grant access to additional data about the bean

      • This also allows to retrieve the underlying contextual instance

    • Added WeldBeanConfigurator to API - allows to select an @Alternative which was created using BeanConfigurator (WELD-2412)

    • We have enhanced the Environment in Weld SPI so that integrators define whether their bean archives are "EE module aware" or not (WELD-2398)

  • Other

    • Under the jboss-as directory of Weld source code, you can now make use of new profiles to create WildFly patches yourself WELD-2397

    • Weld SE and Weld Servlet now explicitly depends on jboss-classfilewriter in version 1.2+ WELD-2406

WildFly Patch

As usual, there is a patch for WildFly 10.1.0.Final is available.

But, for those of you who like to stay sharp, we have also created a patch for WildFly 11.0.0.Beta1.

Please note that there is currently a known issue with security context propagation in Weld 3 for WildFly 11. Though this should only concern people who use the combination of Elytron subsystem and asynchronous CDI events.

If you’re not familiar with patching WildFly, check the FAQ.

Weld Vert.x Next?

2017-8-7   vertx , integration   Martin Kouba

Last year Weld team announced the weld-vertx project (see also Weld meets Vert.x and Update on weld-vertx articles). The goal was clear - bring the CDI programming model into the Vert.x ecosystem. Since then, several things have changed. Two new modules were added, CDI 2 and Weld 3 is now used by default, and two final versions were released. I think it’s a good time to summarize the features and plans for future.

What Is It Good For?

First of all, it offers a mature component model for business logic in your Vert.x applications. A reasonable component model helps making your applications maintainable and scalable in terms of development and reusability. So the primary intention is to implement the business logic as CDI beans and use Vert.x APIs for everything else.


So far there are four modules available:

  1. The Core module starts/stops the Weld SE container and to notifies CDI observer methods when a message is sent via Vert.x event bus. Also you can inject io.vertx.core.Vertx and io.vertx.core.Context in any CDI bean.

  2. The Web module allows to configure the router (a component responsible to find the "logic" to handle an HTTP request) in a declarative way, using @org.jboss.weld.vertx.web.WebRoute annotation. Of course, you can register routes programatically. But what if there are hundreds of routes? The more complicated the REST API is the more difficult it is to maintain the code.

  3. The Service Proxy module makes it possible to inject and invoke service proxies (as defined in

  4. The Probe module enables Weld Probe development tool in a Vert.x application.

How Do I Use It In My Vert.x Webapp?

Let’s enhance an existing webapp in four simple steps.

1. Project Configuration

Jus add the following dependency to your pom.xml and beans.xml into src/main/resources/META-INF (this will enable CDI).

This also brings in org.jboss.weld.vertx:weld-vertx-core, Vert.x and Weld dependencies.

2. Start CDI Container

Deploy WeldWebVerticle and configure router:

class MyVertxApp {
         public static void main(String[] args) {
             final Vertx vertx = Vertx.vertx();
             // ...deploy other existing verticles
             final WeldWebVerticle weldVerticle = new WeldWebVerticle();
             vertx.deployVerticle(weldVerticle, result -> {
                 if (result.succeeded()) {

3. Observe Events

Create a CDI observer method to consume messages from the Vert.x event bus. @VertxConsumer qualifier is used to specify the address the consumer will be registered to. VertxEvent is a wrapper of a Vert.x message.

    class HelloBean {
      void consumerWithDependencies(@Observes @VertxConsumer("hello.address") VertxEvent event, HelloService service) {
        // Reply to the message - io.vertx.core.eventbus.Message.reply(Object)
Since we’re working with regular observer methods, additional parameters may be declared (next to the event parameter) - these parameters are injection points.

4. Declare Routes

Annotate a class implementing Handler<RoutingContext> with @org.jboss.weld.vertx.web.WebRoute:

@WebRoute("/hello") // Matches all HTTP methods
    class HelloHandler implements Handler<RoutingContext> {
        HelloService service;
        public void handle(RoutingContext ctx) {

This will be translated into something like:

void integrationPseudoCode() {
      HelloHandler hello = produceInjectedInstanceOfHelloHandler();
      Router router = obtainRouterInstance();
@WebRoute is repeatable, i.e. if multiple annotations are declared on a handler class a single handler instance is used for multiple routes.

5. Enjoy and Celebrate

And that’s it. Fairly straightforward, isn’t it?

Future and Plans

So far there are no new features on the roadmap. The plan is to provide bugfix releases as needed. But weld-vertx is an open source project and so the future is in hands of the community. Feel free to create issues, share ideas, throw feature requests and send pull requests!

Weld 2.4.4.Final

2017-6-14   release   Matej Novotny

We have been busy chasing down some annoying little bugs and it’s high time you got the fruits of those efforts into your hands. Say hello to Weld 2.4.4.Final.

Notable fixes and improvements:

  • Weld Core

    • Fixed bean discovery event ordering when processing producers (WELD-2393)

    • Eliminated an NPE for a corner case with abstract decorator (WELD-2273)

    • Corrected @Initialized(RequestScoped.class) event firing in @PostConstruct callbacks (WELD-2372)

    • Fixed BeanManager.isStereotype() behavior when checking a qualifier annotated with yet another qualifier (WELD-2390)

  • Weld SE

    • Added a convenience static method WeldContainer.current(), a shortcut for CDI.current() with no need to cast the result (WELD-2399)

    • Allowed to specify bean discovery mode for synthetic archives (WELD-2386)

    • Fixed bean class discovery problem when adding whole packages (WELD-2395)

  • Weld Servlet

    • Improved logging and make checks more lenient in case the container is not yet bootstrapped (WELD-2382)

  • Configuration options

    • In SE and Servlet environments, Jandex can now be forcibly prohibited from processing your archives. This is useful when a third-party dependecy brings in some unsupported Jandex version (WELD-2374)

  • Development tools

    • If a deployment validation fails and the development mode is enabled, a simple validation HTML report (which contains a lot of useful information) is generated

      • Users are encouraged to always attach this report when asking a question on the mailing list or any other communication channel

WildFly Patch

As usual, a patch for WildFly is available. Target platform is WildFly 10.1.0.Final. If you’re not familiar with patching WildFly, check the FAQ.

Tour around Weld 3

2017-5-19   Matej Novotny

This post briefly describes all the main CDI 2.0 features and elaborates on Weld-specific features we added on top of that. It is not intended as a deep-dive but rather to give you the overall idea of what is going on and what can the new release offer. So, enough talk, let’s get the show on the road!

Async Events and Notification Options

Up until now, the only way to send events was to do so synchronously. That meant stopping the work of your current thread to instead occupy it with observer resolution and subsequent notification of observer methods. Once all that was done, the thread resumed it’s work.

With CDI 2.0 there are asynchronous events - a 'fire & forget' way of handling things. Here is how to fire such and event and how to observe it:

// nothing new here, plain old Event is used
    @Inject Event<Payload> event;
    public void sendAsyncEvent() {
        // we use a new fireAsync method for asynchronous events
        CompletionStage<Payload> eventResult = event.fireAsync(new Payload()).thenAccept(...);
    public void asyncObserver (@ObservesAsync Payload payload){ … }

Few things to note here - first of all, the return value of fireAsync is CompletionStage allowing you to chain the work for when the event is done. You can follow-up with more tasks, react on exceptional return value and so on. Another noticeable detail is that observers which are to be notified have to have @ObservesAsync annotation. As you might have guessed, an observer can be notified of either synchronous (@Observes) or asynchronous (@ObservesAsync) events but never both!

Apart from this very basic usage, async events allow you to specify NotificationOptions - an option allowing you to tweak the way notification works. From CDI perspective, there is currently only one standardized option and that enables usage of custom executors which will be used for notifications. But the API was designed in a generic way so that implementation can enrich it with its own options. Weld currently offers two more options - timeout and parallel execution - both of which are well described in Weld docs. And here is a snippet showing it in action:

public void sendAsyncEventWithOptions() {
        // we use a secondary version of fireAsync method with NotificationOptions parameter
        event.fireAsync(new Payload(), NotificationOptions.of("weld.async.notification.timeout", 2000));

Configurators API

Another of the key features are Configurators. They are here to ease our work when doing small tweaks in extensions. Here is a snippet showing how easy it can be to register a new bean in AfterBeanDiscovery using configurator. You don’t have to create a new class implementing Bean<X> anymore:

public void addABean(@Observes AfterBeanDiscovery event) {
        // get an instance of BeanConfigurator
          // set the desired data
          //finally, add a callback to tell CDI how to instantiate this bean
          .produceWith(obj -> new Foo());

Following configurators were added:

  • AnnotatedTypeConfigurator

  • InjectionPointConfigurator

  • BeanAttributesConfigurator

  • BeanConfigurator

  • ObserverMethodConfigurator

  • ProducerConfigurator

On top of that, Weld adds one additional configurator - InterceptorConfigurator. This one allows you to observe WeldAfterBeanDiscovery and then use this configurator to create and register a custom interceptor from scratch.

SE Bootstrap API

A big change in CDI 2.0 is the SE support. Of course, Weld fans have had this for years now, but it has gone official, so that still counts, right?

The official CDI API is very similar to that of Weld, here is how it looks like:

public void bootBasicContainer() {
        SeContainerInitializer initializer = SeContainerInitializer.newInstance();
        try (SeContainer container = initializer.initialize()) {

This is the very basic way; you can also opt to use synthetic bean archive where you cherry-pick all the beans/interceptors/…​ in your archive. CDI spec describes this fairly well, so how about we instead shift our attention to what Weld SE offers on top of that?

A small reminder of how to boot SE container using pure Weld API:

public void bootWeldSeContainer() {
        Weld weld = new Weld();
        try (WeldContainer container = weld.initialize()) {

One of the things Weld makes easier, is when you want to create a quick extension, but don’t really want to write a whole new class which you then need to place in META-INF/services or register on bootstrap. You can easily create a 'synthetic extension' programatically:

Extension testExtension = ContainerLifecycleObserver.extensionBuilder()
        .add(afterBeanDiscovery((e) -> System.out.println("Bean discovery completed!")))
        .add(processAnnotatedType().notify((e) -> {
                if (e.getAnnotatedType().getJavaClass().getName().startsWith("")) {
    try (WeldContainer container = new Weld().addExtension(testExtension).initialize()) {
        // Use the container...

What we just did was to create an extension with two container lifecycle observer methods. It follows a familiar builder pattern and the body of the observer methods is specified as lambda expression. Before booting SE container, we register this extension as we would any other. For more information about this, don’t hesitate to check our older news post.

On-demand Request Context Activation

Especially in SE (although not only there) you might want to activate a RequestContext manually for certain period of time. There are two ways to achieve that, first of which is an interceptor - @ActivateRequestContext. You can use that on either a method or a type (enabling it for all methods). As you might expect, it will activate the context before executing your method and shut it down afterwards. The other way is through means of built-in bean named RequestContextController. This bean can be injected as any other CDI bean and offers to self-explanatory methods: activate and deactivate. The obvious advantage of this approach is that you can enable the context for an extended period of time.

Observer Method Ordering

A small but noteworthy improvement to observer methods. You can not leverage @Priority annotation in observer methods hence ordering them as you wish.

public void observeFirst (@Observes @Priority(1) EventPayload payload) {...}
    public void observeSecond (@Observes @Priority(2) EventPayload payload) {...}

Intercepting Produced Beans

Up until now, anything you created using producers could not be easily intercepted. CDI 2.0 allows this for @AroundInvoke interceptors in two ways. There is a new method on BeanManager named createInterceptionFactory but most of the time you will rather use a built-in bean InterceptionFactory which can be injected as a producer method parameter. Here is a snippet:

    public ProducedBean produceFoo(InterceptionFactory<ProducedBean> factory) {
        return factory.createInterceptedInstance(new ProducedBean());

To explain this a bit, we first inject the built-in bean with the type equal to the produced type we wish to intercept. Then we configure() it, which returns an AnnotatedTypeConfigurator allowing us to add interceptor binding. Finally, we invoke InterceptionFactory.createInterceptedInstance() which takes a the object we produce as a parameter.

You can read more about this in this CDI spec chapter.

Trimmed Bean Archives

Last but not least feature we will mention are so called 'trimmed' bean archives. You can mark an explicit bean archive as trimmed in beans.xml by adding the </trim> element. Such bean archive will perform an annotated type discovery as with bean-discovery-mode="all" but all types that don’t have a bean defining annotation or any scope annotation are then removed from the set of discovered types.

Even in this case, Weld allows you to go one step further and veto types based on regular expression. It works on a similar principle but affects your whole application - it processess all types from all bean archives. Your archives will be scanned as they would be with bean discovery mode all and ProcessAnnotatedType will be fired for all found annotated types. Then, based on the regular expression you provide, annotated types which do not have a bean defining annotation and match the regular expression will be vetoed.