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

The next experimental Weld version has been released! See also the release details. Thanks to everyone involved in this release! This release includes a lot of bugfixes and improvements (e.g. all the notable tasks implemented in the latest stable version: Weld 2.3.4.Final). However, the main goal of this release is to align with CDI API 2.0.Alpha4, and in particular to implement the current version of "metadata builders" API (CDI...

Weld 2.3.4.Final the next version of the stable 2.3 branch has been released! See also the release details. Thanks to everyone involved in this release! Notable bugfixes and improvements: log important actions performed by extensions (WELD-2134) for example, if you want to track down all extensions modifying AnnotatedType definitions, then enable the debug logging for Weld and look for messages containing ProcessAnnotatedType.setAnnotatedType() called by …​ Conversations - allow to...

Vert.x defines itself as "a toolkit for building reactive applications on the JVM". Sounds cool and trendy. Weld, on the other hand, comes from the Java EE world, based on standards and traditional concepts. But wait, what if we try to combine the two worlds to get the best of them? Vert.x makes use of a light-weight distributed messaging system to allow application components to communicate in a loosely coupled way. This...

Weld 2.3.3.Final the next bug-fix version of the stable 2.3 branch has been released! See also the release details. Thanks to everyone involved in this release! Notable improvements: allow to proxy classes with non-static non-private final methods this is a non-portable way to get around the CDI spec restrictions, see also Proxying classes with final methods and CDI-527 use with caution! other enhancements and bug-fixes...

Last week Weld 3.0.0.Alpha15 was released and so it’s time to reveal the features that should go into the next experimental release. The main goal of Weld 3.0.0.Alpha16 is to reflect the output of CDI-558. However, we would also like to continue to deliver experimental prototypes so that users could test a new functionality (that we find interesting and useful) and the CDI EG could eventually...

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