News

Weld 2.4.6.Final

2017-12-18   release   Matej Novotny

Time has come for another round of Weld 2.4 bugfix release. But that’s not all - this time there is also new API to go along with this release - Weld API 2.4.SP2.

Among other things you can now obtain interceptor binding from javax.interceptor.InvocationContext, use enriched version of javax.enterprise.event.Event or select javax.enterprise.inject.Instance based on java.lang.reflect.Type.

Notable fixes and improvements:

  • Weld Core:

    • Improved subclass generation mechanism for generic interceptors (WELD-2414)

    • Corrected proxy creation for signed classes (WELD-2425)

    • Correct InjectionPoint bean behaviour when used within AfterBeanDiscovery observer (WELD-2429)

  • Weld SE

    • There are now multiple convenient error-proof methods to quickly configure SE container (WELD-2426)

      • Weld.enableDevMode(), Weld.scanClasspathEntries(), …​

  • Weld API/SPI

    • WeldInstance has several improvements

      • It now allows you to select() beans based on java.lang.reflect.Type (WELD-2427)

      • WeldInstance.Handler had become lazy which means you can now iterate/filter/sort WeldInstance without actually instantiating beans (WELD-2258)

    • There is new interface in the API - WeldEvent - which can be used in place of well known Event but allows you narrow down event type by using select() with java.lang.reflect.Type (WELD-2427)

    • API now contains WeldInvocationContext, an enriched version of javax.interceptor.InvocationContext which allows to obtain interceptor binding (WELD-2433)

      • There is also a String key used to obtain interceptors binding directly from InvocationContext (WELD-2436)

      • In order to learn more, please refer to (our documentation)

  • Other

    • Probe - fixed NPE which might occur when bean had @Priority but no other annotation (WELD-2432)

    • All the API changes should now be documented within Weld docs

WildFly Patch

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


Weld 3.0.2.Final

2017-11-23   release   Matej Novotny

Weld 3.0.2.Final is out and targetting WildFly 11! Ever wished you could select events and instances in a truly generic way using just java.lang.reflect.Type? Looking for easier way to configure SE container? We have a bunch of bugfixes and improvements for you, so read on…​

Notable fixes and improvements:

  • Weld Core

    • Improved subclass generation mechanism for generic interceptors (WELD-2414)

    • Fixed OSGi bundling, we missed out one package on last release (WELD-2421)

    • Improved behaviour with no-interface EJB view with non-public methods (WELD-2430)

    • Corrected proxy creation for signed classes (WELD-2425)

  • Weld SE

    • There are now multiple convenient error-proof methods to quickly configure SE container (WELD-2426)

      • Weld.enableDevMode(), Weld.scanClasspathEntries(), …​

  • Weld API/SPI

    • WeldInstance has several improvements

      • It now allows you to select() beans based on java.lang.reflect.Type (WELD-2427)

      • WeldInstance.Handler had become lazy which means you can now iterate/filter/sort WeldInstance without actually instantiating beans (WELD-2258)

    • There is new interface in the API - WeldEvent - which can be used in place of well known Event but allows you narrow down event type by using select() with java.lang.reflect.Type (WELD-2427)

    • API now contains a String key used to obtain interceptors binding from InvocationContext (WELD-2436)

  • Other

    • Probe now correctly recognizes beans which have @Priority but aren’t alternatives (WELD-2432)

    • Multiple documentation improvements regarding all things, old and new (WELD-2440, WELD-2431, WELD-2434)

WildFly Patch

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

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


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.

Modules

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 https://github.com/vert-x3/vertx-service-proxy).

  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).

<dependency>
      <groupId>org.jboss.weld.vertx</groupId>
      <artifactId>weld-vertx-web</artifactId>
      <version>${version.weld-vertx}</version>
    </dependency>
Note
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()) {
                     vertx.createHttpServer().requestHandler(weldVerticle.createRouter()::accept).listen(8080);
                 }
             });
         }
     }

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.

@ApplicationScoped
    class HelloBean {
    
      void consumerWithDependencies(@Observes @VertxConsumer("hello.address") VertxEvent event, HelloService service) {
        // Reply to the message - io.vertx.core.eventbus.Message.reply(Object)
        event.setReply(service.hello());
      }
    }
Note
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> {
    
        @Inject
        HelloService service;
    
        @Override
        public void handle(RoutingContext ctx) {
            ctx.response().setStatusCode(200).end(service.hello());
        }
    }

This will be translated into something like:

void integrationPseudoCode() {
      HelloHandler hello = produceInjectedInstanceOfHelloHandler();
      Router router = obtainRouterInstance();
      router.route("/hello").handler(hello);
    }
Note
@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!