Weld/CDI 的最佳调试技巧是什么？
Java EE 6 的优点之一是新的依赖注入框架 - 具有 Weld 参考实现的 CDI - 它促使我们开始以与实现无关的方式内部迁移到 JSR-330，其明确的目标是能够拥有核心 jar 被冻结，然后能够添加额外的 jar，提供新的模块来替换核心 jar 中的功能。
我现在正在与 Weld 一起完成上述工作，坦率地说，幕后有太多的魔力。它要么有效，要么无效，并且默认情况下它不会对发生的情况提供太多帮助，因此您可以调查问题所在并修复它。
我希望有一些开关可以轻松启用以下功能：
- 扫描哪些类路径条目以及在哪里？结果如何？
- 哪些豆类可用于哪个类别的注射？
- 是什么导致稍后不考虑给定的 bean？给定的罐子？
换句话说，我需要更详细地了解决策过程。由于某种原因，Guice 并不需要这样做，也许是因为魔法少得多，也许是因为错误消息非常好。
您如何调试 Weld 应用程序？它有多大帮助？
One of the beauties with Java EE 6 is the new dependency injection framework - CDI with the Weld reference implementation - which has prompted us to start migrating internally to JSR-330 in an implementation agnostic manner, with the explicit target of being able to have a core jar which is frozen, and then being able to add extra jars providing new modules replacing functionality in the core jar.
I am now in the process of making the above work with Weld, and to be frank there is simply too much magic going on behind the covers. Either it works or it doesn't, and it doesn't provide very much help by default on what happens so you can investigate what is wrong and fix it.
I would expect that there are switches to switch which can easily enable things like:
- What classpath entries are scanned and where? What was the result?
- What beans are available for injection for which class?
- What caused a given bean not to be considered for later? A given jar?
In other words, I need to see the decision process in much more detail. For some reason this is not as needed with Guice, perhaps because there is much less magic, and perhaps because the error messages are very good.
What do you do to debug your Weld applications, and how much does it help?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
简短的回答：CDI 没有专用的调试选项（因为规范不需要这样的东西），Weld 也没有专用的调试选项。
长答案：您可以自己做很多事情。熟悉CDI的扩展机制，您会发现您可以轻松（真的！）编写自己的扩展来调试您所需的信息
监听 ProcessAnnotatedType 事件
查询 BeanManager 即可。
监听
AfterBeanDiscovery-Event 并查看 BeanManager 中的内容。基本上，以下场景使 ManageBean 不符合注入条件：@Type{})Short answer: there is no dedicated debug option for CDI (as no such thing is required by the spec), and no dedicated debug option for Weld.
Long Answer: There is a lot you can do on your own. Familiarise yourself with the extension mechanism of CDI, and you'll discover that you can easily (really!) write your own extension that debugs your required information
Listen to the
ProcessAnnotatedType-EventQuery the BeanManager for that.
Listen to the
AfterBeanDiscovery-Event and see what you've got in the BeanManager. Basically, the following scenarios make a ManageBean ineligible for injection:@Type{})Weld 使用 Java 简单日志记录 (sl4j)。如果您使用 Tomcat，我建议您将
sl4j-jdk14-xxxjar添加到应用程序类路径，并将以下行附加到apache-tomcat-7.0.x/conf/logging.properties>：这将在控制台中生成大量调试信息，因此您最好选择特定的内容并注释掉其他行。
其他日志库（如 log4j）可以使用各自的配置文件并添加类似的级别进行配置。
Weld uses Simple Logging for Java (sl4j). If you are using Tomcat, I suggest you add
sl4j-jdk14-x.x.x.jarto application class path and append following lines toapache-tomcat-7.0.x/conf/logging.properties:This will generate lots of debug in console, so you`d better select something specific and comment out other lines.
Other logging libraries (like log4j) can be configured using their respective config files and adding similar levels.
我可以建议一些选项：
降低日志记录阈值。我不知道 Weld 使用什么日志框架，但您可以看到并配置，例如
DEBUG或INFO获取源代码并放置断点在
BeanManager< /a> 实现（也许是 BeanManagerImpl）。它是 CDI 中的主类，处理几乎所有事情。尝试使用不同的实现（如果未与应用程序服务器绑定） - 例如
OpenWebBeans。它的异常消息可能会更好打开规范并阅读有关特定情况的信息。通常情况下，您会错过给定的先决条件 - 例如，注释必须具有特定的
@Target，否则 CDI 不会处理它。我可以确认 Weld 的异常消息相当令人失望。我没有使用过 Guice，但在 Spring 中它们提供的信息非常非常丰富。对于 Weld，我必须参考上面的第四点（打开规范）并验证所有先决条件。这是我最初的怀疑——尽管规范看起来非常好，但实现不会那么闪亮（至少一开始是这样）。但我想人们已经习惯了这一点。
I can suggest a few options:
lower the logging threshold. I don't know what logging framework is used by Weld, but you can see that and configure, say,
DEBUGorINFOget the source code and put breakpoints in the
BeanManagerimplementation (BeanManagerImplperhaps). It is the main class in CDI and handles almost everything.Try putting a different implementation (if not tied by the application server) - for example
OpenWebBeans. Its exception messages might be betterOpen the specification and read about the particular case. It is often the case the you have missed a given precondition - for example an annotation has to have a specific
@Target, otherwise it is not handled by CDI.I can confirm that the exception messages of Weld are rather disappointing. I haven't used Guice, but in Spring they are very, very informative. With Weld I had to refer to the 4th point above (opened the spec) and verify all preconditions. This was my suspicion initially - that even though the spec looks very good, the implementations will not be as shiny (at first at least). But I guess one gets used to this.