CDI and JANDEX and deployment enhancement approach

Question

I am opening this thread as I was requested to do so, in a reply to comment/question i added here: Disable scanning of CDI beans in WAR

The question is the following. Is there any specific additional step that one needs to take besides adding jandex to his build pom to get the feature enabled? I notice no deployment speed difference when using jandex on Wildfly 10.1.0.Final and Weblogic 12.2.1.2 deployments. If anything, the deployment tends to be about 1 second slower.

Steps taken: 1. Visit https://github.com/wildfly/jandex-maven-plugin

2. Enrich a multi-module pom with the plugin

<plugin>
  <groupId>org.jboss.jandex</groupId>
  <artifactId>jandex-maven-plugin</artifactId>
  <version>1.0.5</version>
  <executions>
    <execution>
      <id>make-index</id>
      <goals>
        <goal>jandex</goal>
      </goals>
      <!-- phase is 'process-classes by default' -->
      <configuration>
        <!-- Nothing needed here for simple cases -->
      </configuration>
    </execution>
  </executions>
</plugin>   

3. Notice that all .jar files have a size relatively larger due to the contained Jandex.idx that gets written to the META-INF/

4. Deploy the WAR application via wildfly/weblogic console

5. No difference at all in deployment time. And on this point, believe me, the application is not light-weight on the number of CDI beans it holds. This is something being addressed, but as a short-time solution I would like to find a quickfix to accelerate the deployment time and was hoping Jandex to have some impact.

Instead it seems to make 0 difference, if anything the deployment with jandex always seemed to take one to two seconds extra.

Perhaps additional information that might be relevant.

Both in wildfly and in weblogic, there is a tunning that can be done to tell the newer versions of WELD to not scan all deployed .jar files. We use the setting that tells weld to only consider jar files with the beans.xml file within them.

And these jar files have bean-discover="all" - while CDI recommends that one uses the "annoted" approach to speed up analysis time and memmory foot print (but that would require a bigger refactoring).

See http://weld.cdi-spec.org/news/2016/10/25/tip3-performance/

So in short: Is there something more that needs to be done to tell a container to consider the jandex index. Or is it simply that Weld is already so fast analyzing the deployed classes, that pre-building the index makes virtually no difference except to add up to the deployment a few MBytes?

• I would assume not because Jandex is still mentioned as weld tip for deployment speed improvement, so I am tempted to think I am missing some piece of configuration.

Many thanks for any help on this front.

Answer 1

You are right - this won't be faster. It would be (most likely) in SE and Servlet but not necessarily in EE server.

Weld SPI offers a service interface to integrators (such as WildFly and WebLogic) and they may or may not choose to use it and feed Weld with class info (from Jandex for instance). Now, I don't know about WebLogic, but I guess they don't use Jandex at all (it's WFLY sub-project after all). But when we talk WildFly, they do use Jandex, but they create their own Jandex index "on-the-fly" during deployment which they then use instead of the pre-prepared one you might have had there. That explains the additional second of something you see.

On the other hand, in SE/Servlet environment, Weld is an "integrator" for itself and can (and does) make sure that Jandex will be used.