The development of Weld 3 (CDI 2) is underway. However, we don’t forget about the maintenance of the stable branch of Weld! So I am very pleased to announce the first bugfix version of Weld 2.4 (CDI 1.2). See also the release details. Thanks to everyone involved in this release! Notable fixes and improvements: removed false positive warning about Jandex version used (WELD-2231) fixed Groovy support - only filter out relevant...

Contents Bootstrap Discovery mode Extensions Jandex Runtime Identify problematic components easily Lazy initialization of bean instances Drawbacks of @Dependent pseudo-scope Mapping CDI contexts to HTTP requests Bean identifier index optimization In this article we’re going to dive into various performance aspects of CDI applications. As you’ve probably noticed performance testing is sometimes tricky. First of all, it’s difficult to create a meaningful benchmark. One should understand the JVM...

Contents How to enable the development mode Web application WildFly Weld SE How does it actually work? Probe UI What if I don’t have a webapp? Does it work offline? In this article we’re going to cover the special mode for application development. When enabled, a built-in tool called Probe provides a detailed insight into internals of a CDI application. Probe makes it easy to inspect: bean archives beans and...

Contents Motivation Under the hood Set the log level and use categories to filter messages Monitoring bootstrap Registered beans Actions performed by extensions This is the first article from a series of short articles covering some useful Weld features. In this article we talk about logging. The topics for the next articles include: DEVELOPMENT MODE, PERFORMANCE, NON-EE ENVIRONMENTS and TESTING. Motivation Logging is usually no fancy stuff. But very often it’s the...

I am very pleased to announce the first stable version of Weld 2.4 (CDI 1.2). See also the release details. From now on, 2.4 is the current stable version of Weld and 2.3 is not actively developed anymore. Thanks to everyone involved in this release! Most of the new features were already introduced in First release candidate of Weld 2.4. To sum it up: Removed dependency on com.google.guava...

Contents Removed dependency on com.google.guava:guava Enhanced version of javax.enterprise.inject.Instance Veto AnnotatedType not annotated with bean defining annotation @ActivateRequestScope moved to Weld API Improved rolling upgrades support Events - reflect the output of CDI-494 Probe - allow to filter unused beans Cleanup Initial Java 9 support Bugs WildFly Patch I am pleased to announce the first release candidate of Weld 2.4 (CDI 1.2). See also the release details. Thanks...

We are pleased to announce a release of embedded Arquillian container adapter for Weld. This container has deserved some love for really long time. We tried to refactor it and introduced new master branch which now corresponds to the 2.0.0.x version stream. The original master was branched in 1.0. There is no more any arquillian-weld-ee-embedded-1.1 or arquillian-weld-se-embedded. It’s squashed to one...

The next version of the stable 2.3 branch has been released! See also the release details. Thanks to everyone involved in this release! We plan to create the 2.4 branch of Weld within a few weeks. Weld 2.4 will remain a CDI 1.2 implementation. We would like to do some cleanup (e.g. remove deprecated classes from Weld SE), enhance the API and also add some new features. See also the...

This is a follow-up on the article Weld meets Vert.x. Weld team has just released the first alpha version of weld-vertx (artifacts are available in Maven Central). Since the last time we talked about weld-vertx two new features were added. First, it’s possible to inject the relevant io.vertx.core.Vertx and io.vertx.core.Context instances direcly into beans. Also there is a new module called weld-vertx...

javax.enterprise.inject.Instance is sometimes invaluable companion. For example, Instance allows you to handle unsatisfied and ambiguous dependencies gracefully. E.g. it’s possible to avoid unnecessary deployment problems: interface OrderProcessor { void process(Order order); int getPriority(); } class OrderService { @Inject Instance<OrderProcessor> instance; void create(Order order) { if (!instance.isUnsatisfied() && !instance.isAmbiguous()) { instance.get().process(order); } else { // Log a warning or throw an exception } } } It is less known that...