CDI 和 JANDEX 以及部署增强方法 - 未检测到速度差异 [英] CDI and JANDEX and deployment enhancement approach - no speed difference detected

问题描述

我按照要求打开此线程，在回复评论/问题时，我在此处添加:在 WAR 中禁用 CDI bean 扫描

问题如下.除了将 jandex 添加到他的构建 pom 以启用该功能之外，是否还需要采取任何特定的额外步骤?在 Wildfly 10.1.0.Final 和 Weblogic 12.2.1.2 部署上使用 jandex 时，我注意到没有部署速度差异.如果有的话，部署往往会慢 1 秒左右.

采取的步骤:1.访问https://github.com/wildfly/jandex-maven-plugin

2. 使用插件丰富多模块 pom

<块引用>

<groupId>org.jboss.jandex</groupId><artifactId>jandex-maven-plugin</artifactId><version>1.0.5</version><执行><执行><id>make-index</id><目标><goal>jandex</goal></目标><!-- 阶段是默认的进程类"--><配置><!-- 对于简单的情况，这里不需要任何东西--></配置></执行></执行></插件>

3. 请注意，由于包含被写入 META-INF/的 Jandex.idx，所有 .jar 文件的大小都相对较大

4. 通过 wildfly/weblogic 控制台部署 WAR 应用程序

5. 部署时间完全没有区别.在这一点上，相信我，该应用程序在它拥有的 CDI bean 数量上并不是轻量级的.这是正在解决的问题，但作为一个短期解决方案，我想找到一个快速修复来加快部署时间，并希望 Jandex 产生一些影响.

相反，它似乎产生了 0 差异，如果有的话，使用 jandex 的部署似乎总是多花一到两秒钟.

也许其他可能相关的信息.

在wildfly 和weblogic 中，都可以进行调整以告知较新版本的WELD 不扫描所有已部署的.jar 文件.我们使用设置告诉weld 只考虑包含beans.xml 文件的jar 文件.

并且这些 jar 文件具有 bean-discover="all" - 而 CDI 建议使用注释"方法来加快分析时间和内存占用(但这需要更大的重构).

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

简而言之:是否还需要做更多的事情来告诉容器考虑 jandex 索引.或者仅仅是 Weld 已经如此快速地分析已部署的类，以至于预构建索引几乎没有任何区别，只是为部署增加了几个 MBytes?

• 我不认为是因为 Jandex 仍然被提及作为用于提高部署速度的焊接尖端，所以我很想认为我缺少一些配置.

非常感谢您在这方面的任何帮助.

解决方案

你说得对 - 这不会更快.它(最有可能)在 SE 和 Servlet 中，但不一定在 EE 服务器中.

Weld SPI 为集成商(例如 WildFly 和 WebLogic)提供服务接口，他们可能会或可能不会选择使用它并向 Weld 提供类信息(例如来自 Jandex).现在，我不了解 WebLogic，但我想他们根本不使用 Jandex(毕竟它是 WFLY 子项目).但是当我们谈论 WildFly 时，他们确实使用了 Jandex，但是他们在部署期间即时"创建了自己的 Jandex 索引，然后他们使用该索引而不是您可能在那里预先准备好的索引.这就解释了你看到的东西多了一秒.

另一方面，在 SE/Servlet 环境中，Weld 本身就是一个集成器"，可以(并且确实)确保使用 Jandex.

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.

解决方案

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.

这篇关于CDI 和 JANDEX 以及部署增强方法 - 未检测到速度差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！