What are the best debugging tricks with Weld/CDI?

Question

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?

Fokker

Answer 1

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

What classpath entries are scanned and where? What was the result?

Listen to the ProcessAnnotatedType-Event

What beans are available for injection for which class?

Query the BeanManager for that.

What caused a given bean not to be considered for later? A given jar?

Listen to the AfterBeanDiscovery-Event and see what you've got in the BeanManager. Basically, the following scenarios make a ManageBean ineligible for injection:

• it's no ManagedBean (like there is no beans.xml in the jar)
• it does not qualify as a managed bean (https://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html/beanscdi.html#d0e794)
• it has no BeanType (@Type{})
• it is vetoed (Seam Solder) or suppressed by any other extension-mechanism

Catboat

Nice info. Are you aware of anybody who has written a "drop this in and get lots of info"-module, instead of me having to do the prerequisite research first? – Thunder

No extension that I'm aware of. Would make a nice contribution to Seam / CODI though... – Catboat

I don't think that it works because you can't specify the order of the extensions. So an extension which is called afterwards can still change the game. – Assisi

I now have the problem again. Are you familiar with any development in this area for newer versions of Weld? – Thunder

Answer 2

Weld uses Simple Logging for Java (sl4j). If you are using Tomcat, I suggest you add sl4j-jdk14-x.x.x.jar to application class path and append following lines to apache-tomcat-7.0.x/conf/logging.properties:

org.jboss.weld.Bootstrap.level = FINEST 
org.jboss.weld.Version.level = FINEST 
org.jboss.weld.Utilities.level = FINEST 
org.jboss.weld.Bean.level = FINEST 
org.jboss.weld.Servlet.level = FINEST 
org.jboss.weld.Reflection.level = FINEST 
org.jboss.weld.JSF.level = FINEST 
org.jboss.weld.Event.level = FINEST 
org.jboss.weld.Conversation.level = FINEST 
org.jboss.weld.Context.level = FINEST 
org.jboss.weld.El.level = FINEST 
org.jboss.weld.ClassLoading.level = FINEST

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.

Soemba

Answer 3

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, DEBUG or INFO

• get the source code and put breakpoints in the BeanManager implementation (BeanManagerImpl perhaps). 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 better

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

Optime

I'm not tied right now by the application server. It is the blueprints of how to do the "frozen core jar + extra functionality jar" in each JSR-330 provider, that I am doing for CDI now. Does OpenWebBeans have better error reporting? Have you had a look at the CanDI implementation in Resin? My logging configuration may cut off DEBUG logs, I'll have a look. – Thunder

I haven't had any experience with OWB or CanDI. Only Weld, and not too much actually. – Optime

OpenWebBeans e.g. logs the scanned JAr files. If you miss something create a JIRA issue. They are very innovative and I guess they will implement such features. – Assisi