News - tagged as "tips"

Weld Tip 4 - Testing CDI/Weld apps

2017-2-1   tips   Tomas Remes, Matej Novotny

In this follow-up article of our Weld Tips series we are going to focus on testing of CDI/Weld applications. Let’s discover options for unit testing in the first part and then continue with integration testing. To set things straight - by integration testing we mean testing in some kind of container and hence in certain environment (SE, servlet, full EE server). However, no matter the environment we always make use of Arquillian integration testing framework.

Using Weld in JUnit tests

Recently we created Weld JUnit extension which uses JUnit4 @Rule to initialize a Weld SE container before each test method execution. For further information please check following blogpost.

Arquillian as the chosen framework for testing

While Arquillian may look complex at first, it is certainly worth it. Here are some of the advantages it gives you:

  • Allows usage of CDI @javax.inject.Inject directly in test classes

  • Works well with ShrinkWrap making archive creation and deployment a breeze

    • ShrinkWrap can create any type of deployment archive (WAR, JAR, even infamous EAR) with exactly the capabilities you wish it to have

    • You can use dedicated beans.xml or @Alternatives for given test case

  • Portability - allows to write one test and run it on any container

    • Arquillian only needs correct adapter; therefore, combined with Maven profiles this gives you some nice fire power for matrix testing

  • Allows for very complex testing scenarios

    • For instance you can create several deployments which you then manually (if you so wish) deploy/undeploy

    • This makes it viable even for cluster testing (session replication, failover scenarios, …​)

  • Can start the application server itself or can just connect to running one

In fact writing tests with Arquillian is quite straightforward. It’s basically about right usage of right annotations. Basic test could like this:

 package org.arquillian.example;
     import javax.inject.Inject;
     import org.jboss.arquillian.container.test.api.Deployment;
     import org.jboss.arquillian.junit.Arquillian;
     import org.jboss.shrinkwrap.api.ShrinkWrap;
     import org.jboss.shrinkwrap.api.asset.EmptyAsset;
     import org.jboss.shrinkwrap.api.spec.JavaArchive;
     import org.junit.Assert;
     import org.junit.Test;
     import org.junit.runner.RunWith;
     public class GreeterTest {
         // This static method builds the virtual test deployment archive
         public static JavaArchive createDeployment() {
             return ShrinkWrap.create(JavaArchive.class)
                 .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
         Greeter greeter;
         public void should_create_greeting() {
            Assert.assertEquals("Hello, Earthling!", greeter.createGreeting("Earthling"));

If you are a complete Arquillian rookie, you might want to look at their Getting started guide. Should you just need an inspiration, you needn’t look any further than our testsuite. To support the though of Arquillian usefulness for CDI/Weld testing, we may also point out that even CDI TCK tests use it.

Now, let’s take a look at different environments and then round it up with Arquillian Weld Embedded container, which can be used in each and every environment.

Java EE application server

When you want to test your application in Java EE application server you basically need to create your test deployment archive, deploy it, execute the test and undeploy the archive. As stated above, ShrinkWrap covers the archive creation (typically WAR or EAR). When it comes to deployment/undeployment, Arquillian controls that, unless you take the reins and control it yourself - just keep an eye for dangling deployments. You also get to chose between using so called managed container, where Arquillian starts and stops the desired container for you, and remote container where Arquillian tries to connect to already running container. Since we are talking Java EE application server, you can use CDI out of the box. Just pay attention to test mode you are using. You can check available Arquillian container adapters here.

For example to use Arquillian WildFly Managed container you need to define following dependency:


Servlet environment

In basic Servlet environment you need to deploy all the dependencies of Weld Servlet integration (as CDI API, Interceptors API, etc.) to your Servlet container and thus embedded container option could be sufficient. As you can see Arquillian offers embedded container adapters for all well known Servlet containers such as Tomcat, Jetty and Undertow.

For example to use Arquillian Embedded Tomcat container you need to define following dependency:


Java SE environment

Java SE is not effectively a container, however it could be very handy to have an option to easily configure classpath elements of your test. This is exactly what Arquillian container SE offers. With this extension you can build your test classpath and the test executes remotely over JMX in new isolated JVM process. You can find basic information in README or you can take look into already mentioned CDI TCK tests where you can find SE testgroup which involves all SE related tests.

The maven dependency for this extension looks like this:


Arquillian Weld Embedded container

First of all - this test container is suitable in situations when you know you don’t need to work with full Java EE application server and you are OK with dummy mock EJB, JTA, JPA etc. services. As stated in the beginning of this article, you can use it for any environment but you have to keep it mind, that other technologies/services will be mocked only. By default, this container operates in SE mode, as you don’t need to mock anything there, but you can use a system property (Denvironment=EE) or a programmatic approach in order to make it work in other environments. For full list of supported environments, see We recommend you to take a glance at README file - especially those few lines about flat deployment structure (this means this container is not very suitable for testing EAR deployments) and configuration property for setting testing environment.

The maven dependency for this container could look like this:


Weld Tip 3 - Boost performance of Weld apps

2016-10-25   tips   Martin Kouba

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 specifics (the need for warmup, garbage collection, JVM settings, etc.) and also use appropriate tools (e.g. JMH for microbenchmarks) accordingly. But even that usually proves to be unsufficient. One should also run the test in a relevant context (data, load, etc.). Performance specialists also say that’s it’s good to avoid premature optimizations but keep performance aspects in mind when tuning the "final" code. But all these considerations are out of scope of this article. Let’s go through several areas where CDI affects the performance of your application and discuss the possibilities.


During bootstrap the overhead of a framework should be minimal so that it does not slow down the application startup and also does not eat all the memory available. However, CDI needs to do all that magic behind the scenes - read annotations, build and validate metadata, etc. The following sections describe what could be done to minimize the impact.

Discovery mode

In CDI 1.0 there was only one "discovery mode". How does it work? Simply put: find all bean archives (containing beans.xml), discover and process all the found classes (identify beans, etc.). Needless to say, this might be a performance problem for large applications with thousands of classes. In CDI 1.1+ we call this mode all and a bean archive with this mode is called EXPLICIT. Since CDI 1.1+ a new discovery mode - annotated - can be used. The difference is that if this mode is used only classes with a bean defining annotation are considered. In other words, a component must be explicitly designated. A bean archive with this mode is called IMPLICIT. To make things a little bit more complicated, an implicit bean archive does not have to contain a beans.xml file at all. One class with a bean defining annotation or a session bean is enough.

Implicit bean archive has pros and cons:

  • saves a lot of memory if an archive contains a lot of classes which should NOT become beans (the container does not have to store the metadata)

  • speeds up the bootstrap (the container does not have to process all the types, fire events like ProcessBean, etc.)

  • does not fire ProcessAnnotatedType for all types from the bean archive; this breaks some extensions (e.g. MessageBundleExtension from DeltaSpike)

  • does not pick up @javax.inject.Singleton beans (it’s not a bean defining annotation)

CONCLUSION: If possible, use the annotated discovery mode.

Most Weld-based runtimes allow to suppress implicit bean archives without beans.xml, i.e. to require the beans.xml file in bean archives so that it’s not necessary to scan all the parts of the application. See also FAQ.
If it’s not possible to use annotated mode, you can try a Weld-specific feature to conserve memory used: Veto types without bean defining annotation. A similar solution is going to be standardized in CDI 2.0 (see also CDI-420).


CDI portable extensions are essential integration points. And users love integrated technologies. However, the more extensions the more work must be done during bootstrap. For example, there is a ProcessAnnotatedType container lifecycle event. This event is fired:

  • for every type in an EXPLICIT bean archive,

  • for every session bean and every type with a bean defining annotation in an IMPLICIT bean archive.

The delivery might be restricted by means of type arguments, e.g. for observer void observeNumbers(@Observes ProcessAnnotatedType<? extends Number> event) an extension will be notified for every class assignable to Number. However, if you do <T> void observe(@Observes ProcessAnnotatedType<T> event) your extension will be notified for every class that is discovered. Now if we have an application with one EXPLICIT bean archive with 2000 classes, then a specific observer method on such extesion will be called 2000x. And if there are three similar extensions, the CDI container will have to create 2000 events and notify 6000 observers. This should be ok unless the observer logic is overly complex.

CONCLUSION: Pay attention to extensions used in your application. If you wonder what extensions are in service, use for example Weld Probe observers view or fired events view together with org.jboss.weld.probe.eventMonitor.containerLifecycleEvents enabled.

If possible, don’t use the extensions which observe all the annotated types from your application, i.e. which defined something like void observe(@Observes ProcessAnnotatedType<?> event). Since CDI 1.1 @WithAnnotations should be used to restrict the set of types an extension is going to process. Weld Probe warns you about these extensions.


In some environments (WildFly, Weld SE, and more) Weld can leverage an "offline reflection library", such as Jandex, to speed up the scanning process. These libraries allow to effectively filter classes which are not beans and vetoed classes. It works like this: Jandex generates an index (scans the bytecode) and Weld is using this index to filter out useless classes. As a result Weld does not even have to _load the classes or use reflection API to detect types which should be ignored.

In Weld SE and Servlet it’s also possible to generate the Jandex index beforehand, e.g. using the Ant task.


In runtime the overhead of a framework should be minimal so that it’s not an application bottleneck. However, CDI needs to do all that magic behind the scenes - create bean instances, manage contexts, intercept and decorate invocations, etc. The following sections describe what could be done to minimize the impact.

Identify problematic components easily

Before you start a profiler or a similar tool, it’s a good idea to identify all the CDI components involved in a problematic "request". This means all the beans, observer methods, interceptors and decorators. The good start might be the Weld Probe invocation trees view. An invocation tree shows all the business method invocations (including producers, disposers and observer methods). Once you spot a problematic component, you can check the business logic and associated interceptors and decorators. Sometimes profilers are just an overkill.

Lazy initialization of bean instances

Weld initializes bean instances of normal scoped beans lazily. In other words, when injecting a normal scoped bean (@RequestScoped, @ApplicationScoped, etc.) a new instance is not created until actually used. Instead, a shared client proxy is injected. This proxy invokes a method upon the correct bean instance (created if necessary).

Having many injection points resolving to normal scoped beans does not necessarily mean additional overhead associated with bean instance creation.

In the following example, an OrderProcessor instance is not created until its OrderProcess.process() method is called:

    class OrderProcessor {
      void init() {
        // Do some expensive initialization logic
      void process() {
        // Business logic
    class OrderService {
      OrderProcessor processor; // A shared client proxy is injected
      void create(Order order) {
        if (order.isValid()) {
            // Processor is not initialized unless we have a valid order
Weld’s session context is also initilized lazily and doesn’t require an HTTP session to actually exist until a bean instance must be written (i.e. until a method of a @SessionScoped bean is invoked).

Drawbacks of @Dependent pseudo-scope

From performance point of view @Dependent is NOT a best fit for:

  • a bean that declares a producer which is frequently used (i.e. the produced bean is created very often)

  • a bean that declares an observer method which is frequently notified (i.e. the event is fired very often)

  • a bean which is used in EL expressions

For all these cases, a new @Dependent bean instance is created to handle the logic and destroyed when the invocation/evaluation completes. In other words, the bean instances are not reused. That’s not necessarily a problem if a bean does not have an "expensive" initialization or depends on others "heavyweight" components. But very often, a wider scope is more suitable.

Mapping CDI contexts to HTTP requests

By default, bult-in CDI contexts are activated at the beginning of an HTTP request processing and deactivated once the processing finishes. This might be an unnecessary overhead in certain situations, e.g. when serving static resources (images, JavaScript, etc.). Weld allows to activate the contexts only for a subset of requests only. A regular expression may be used for filtering HTTP requests that should have contexts active during their processing.

<web-app version="3.1" xmlns=""
            <param-value>.*\.html</param-value> <!-- Only activate contexts for resources with html suffix, e.g. /some/path.html -->

Bean identifier index optimization

This optimization is used to reduce the HTTP session replication overhead (clustering use case). Simply put: Weld tries to minimize the amount of bytes send over the network. However, the inconsistency detection mechanism may cause problems in environments where application stop does not imply HTTP session destruction. Thus it’s disabled by default in Servlet containers. See also the reference guide for more info.

Weld Tip 2 - Development Mode

2016-10-7   tips   Martin Kouba

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 their properties such as qualifiers, stereotypes and name

  • a graph of bean dependencies

  • observers and producers declared by beans

  • interceptors and decorators bound to a bean

  • extensions

  • information about current contextual instances

  • tracking of invocations and invocation trees

  • tracking of fired events

  • Weld configuration

  • and more!

Before you start reading, you might want to check the live demo hosted on OpenShift and see what Probe can offer. Ok, now let’s get it working!

How to enable the development mode

No surprise that the development mode is DISABLED by default. It should NEVER be used in production as it may have negative impact on performance and/or represent a potential security risk. Note that if you successfully enable the development mode you should see Weld Development Mode: ENABLED warning in the log during application bootstrap. Make sure to disable the development mode before deploying to production!

Web application

For any web application, set the Servlet initialization parameter org.jboss.weld.development to true:



Since WildFly 10 it’s also possible to enable the Weld development mode globally (i.e. for all the applications deployed) by setting development-mode attribute to true:


Weld SE

For a Java SE application, set the system property org.jboss.weld.development to true:

java -cp myCoolApp.jar -Dorg.jboss.weld.development=true

or use the method:;
    public static void main(String[] args) {
       Weld weld = new Weld().property("org.jboss.weld.development", true);
       try (WeldContainer container = weld.initialize()) {

How does it actually work?

Probe collects CDI-related data from your application and then makes the data available through the REST API, eventually through the MXBean of name org.jboss.weld.probe:type=JsonData,context=ID where ID should be replaced with an idenfitier of an application.

Probe UI

Probe has also a web UI (single-page application) available at {webapp-context-path}/weld-probe (once your webapp starts), e.g. http://localhost:8080/weld-numberguess/weld-probe. By default, Probe also embeds a tiny information bar directly into the application’s HTML output. That makes it easy to navigate to Probe directly from the application anytime. Furthermore, if invocation tracking is enabled, the information bar helps navigate directly to the invocation tree related to the request that rendered the output.

We believe the UI is quite intuitive but feel free to ask questions on any channel (irc, gitter, mailing list, etc.).

There are some configuration properties which allow to tune or disable Probe features, e.g. to restrict the set of components which will be monitored. See also Development Mode Configuration.

What if I don’t have a webapp?

Nothing is lost! JMX and weld-probe-client-adapter come to rescue. This "adapter" allows to reuse the default HTML UI even if there is no REST API available (non-web environments). The adapter either connects to a JMX server (Probe JMX support must be enabled) or loads data from an exported file (see also Does it work offline?), then starts an embedded Undertow webserver instance and exposes the default HTML client but using the data from the first step.

Does it work offline?

Sometimes it’s not possible to inspect a running system (e.g. due to security reasons). Probe allows to export the collected data and inspect it offline. There are two ways to export the data:

  1. Using REST API: HTTP GET {webapp-context-path}/weld-probe/export

  2. Configure Probe to export data after deployment (see also org.jboss.weld.probe.exportDataAfterDeployment property in Development Mode Configuration)

And now use the weld-probe-client-adapter again:

java -jar weld-probe-client-adapter-1.0.0.Final-shaded.jar /home/weld/

Weld Tip 1 - Logging

2016-10-1   tips   Martin Kouba

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.


Logging is usually no fancy stuff. But very often it’s the best thing to start with if problems arise. Moreover, it’s the easiest form of debugging.

In this article you will find:

Under the hood

Weld is using JBoss Logging. This is an abstraction layer wchich does not "write" any log messages at all. Instead, it effectively constructs a log message and then delegates to a back-end logging framework. The supported frameworks include jboss-logmanager, Log4j, SLF4J and JDK logging.

So which logging framework is actually used to write the Weld messages? Well, it depends on the environment. In a Java EE container (e.g. WildFly) the logging configuration is under the direction of the container. You should follow the container-specific guides to change the configuration (see for example WildFly - Logging Configuration and How do I enable debug logging for Weld in a specific container?).

A web application deployed to a servlet container usually bundles a logging framework and possibly some configuration file. In this case, the configuration is in hands of the application developer. If no logging framework is bundled follow the container-specific guides to change the configuration (e.g. Logging in Tomcat).

A system property org.jboss.logging.provider can be used to specify the logging framework directly. If not set, the JBoss Logging will attempt to find the "best match" on the classpath. See also LoggerProviders.

In Java SE the situation is very similar to servlet containers except the class loading is usually even less complicated (see also How do I enable debug logging for Weld SE?).

Set the log level and use categories to filter messages

The default log level is usually INFO. Weld does not log that much information with this level. You will have to set the log level to DEBUG (or even TRACE) to see what’s going on in your application. If you set the level globally (for all frameworks and libraries), the log files will be bloated and it will be very hard to get some relevant info from there. If you set the level for Weld only (i.e. for org.jboss.weld), it should be better. Moreover, it’s possible to use categories to filter messages from a particular "domain". Weld log messages are grouped into several categories:

  • org.jboss.weld.Bootstrap

  • org.jboss.weld.Validator

  • org.jboss.weld.Bean

  • org.jboss.weld.Context

  • org.jboss.weld.El

  • and others (see also org.jboss.weld.logging.Category)

So for example, if you’re only interested in log messages related to EL resolution set the log level for the org.jboss.weld.El category to TRACE (or level with corresponding priority). Another useful example is the check of Weld configuration. Simply set the log level to DEBUG and filter the org.jboss.weld.Configuration category:

DEBUG [Configuration] WELD-001907: Reading properties file: test.war/WEB-INF/classes/
    DEBUG [Configuration] WELD-001903: Configuration key RESOLUTION_CACHE_SIZE already set to 1 000 in a source with higher priority, value 500 from system properties is ignored
    DEBUG [Configuration] WELD-001904: Unsupported configuration key found and ignored:
    DEBUG [Configuration] WELD-001902: Configuration initialized: {CONCURRENT_DEPLOYMENT=false, RESOLUTION_CACHE_SIZE=1000, RELAXED_CONSTRUCTION=true}

Monitoring bootstrap

CDI is designed to fail fast. An extensive validation is performed during application initialization in order to avoid malicious errors at runtime. Container usually also logs a lot of interesting info during bootstrap. Let’s try to set the log level to DEBUG for the org.jboss.weld.Bootstrap category and see what we get.

Registered beans

As simple as it looks - Weld logs all the beans found in the application, e.g.:

DEBUG [Bootstrap] WELD-000106: Bean: Managed Bean [class org.jboss.cdi.tck.tests.lookup.dependency.resolution.broken.unsatisfied.Vanilla] with qualifiers [@Any @Default]
    DEBUG [Bootstrap] WELD-000106: Bean: Producer Method [String[]] with qualifiers [@BatchProperty @Any] declared as [[UnbackedAnnotatedMethod] @Produces @BatchProperty public org.jberet.creation.BatchBeanProducer.getStringArray(InjectionPoint)]

Actions performed by extensions

There is no doubt that portable extensions are really powerful. They can change almost anything. That’s great for framework/libraries developers. On the other hand, this may cause problems when looking for a bug. There is an application class provided by a developer but what does the CDI container actually see? Well, it depends…​ because portable extensions are allowed to redefine this. And that’s why Weld logs all the "modification" operations performed by extensions, such as ProcessAnnotatedType.veto():

DEBUG [Bootstrap] WELD-000148: ProcessAnnotatedType.veto() called by for [BackedAnnotatedType] public class
If your application deploys successfully, you can use Development Tools to inspect the runtime info (will be covered in one of the follow-up articles).