News

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!


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.