Community
Participate
Working Groups
With the growing popularity of load-time weaving it is becoming increasing difficult to diagnose complex problems given the limited diagnostic information available: stack trace, verbose output, and dumped byte-code. For compiler errors it is usually possible for the bug raiser to attach a simple testcase but this is not possible when the problem may concern the environment or integration with middleware. I therefore propose we implement a tracing/logging mechanism that will capture low level entry/exit information as well as existing informational messages (see Ron’s comment in Bug 150271 “Allow multiple levels of LTW information”) and route them to one of the existing logging infrastructures such as JDK 1.4 or Jakarta Commons logging.
Having pluggable logging would be great. Perhaps there could be a configuration option to specify a message handler implementation and AspectJ could bundle implementations for the most popular loggers. For LTW, configuration would most naturally be done via aop.xml. However, that can't configure the bootstrap messages so it might also need to be a -D option. It would be great to see AspectJ advice used to support tracing and possibly logging of repeatable classes of events for this framework, to show the value of developing AspectJ with AspectJ. Naturally there's going to be some reticence to making this switch. So let me offer the counter argument that in fact doing this would be one of the best things the project could do to improve AspectJ. Making all the AspectJ source modules into AspectJ projects in Eclipse would also do a lot to improve usability of AJDT on large, multi-module systems: the classic argument for eating one's own "dog-food", but in this case I think there's a lot to be said for it. AJDT works pretty well on moderate sized standalone projects but when I use it integrated across multiple projects I see issues with over-eager compilation as well as severe visualization limitations...
I have created an interface that supports both low level entry/exit trace to help with debugging as well as a high level debug/info/warn/error interface that could be used by a MessageHandler. This interface plugs into whatever the weaver can find (at the moment java.util.logging or org.apache.commons.logging). I will be writing a MessageHandler, that you can specify in aop.xml using “-XmessageHandlerClass:” in weaver options which will use the new interface. So therefore if you supply the appropriate logging.properties file and use the new message handler LTW messages will be sent wherever you want. You don’t need to use –Daj.weaving.verbose because we save bootstrap messages until we know the verbose status so nothing is lost. WRT using AspectJ in the construction of the compiler itself you are quite right that it would be a good advertisement and a prime example of eating our own cooking. Of course the project is of sufficient size that it suffers the performance problems you describe. At the moment it is a question of priorities.
Added TraceMessageHandler (need to document this somewhere) that can be used with “-XmessageHandlerClass:” for any weaving mode (compile, binary loadtime). Output is sent to the default trace destination i.e. java.util.logging on Javav 5. It will ignore any settings like -verbose and use the trace configuration instead e.g. logging.properties. The name used is "TraceMessageHandler". Just need to include information context information from Bug 150254 (Provide context for LTW verbose messages).
I’ve changed my mind. Instead of a dedicated message handler I have changed the existing LTW handler WeavingAdaptorMessageHandler to always delegate to a default or user-supplied handler. This approach could be adapted for compile and binary weaving. This approach kills 3 birds with one stone: 1. Offers a single point to trace messages when the System property “org.aspectj.tracing.messages” is true regardless of what message handler is specified 2. Allows us to protect against rogue handlers in a runtime environment 3. Could allow multiple handlers in future.
Enhancement committed.
