Community
Participate
Working Groups
The load-time weaving system can produce truly massive quantities of output when there's a weaving error, since the system dumps the bytecode to syserr. It would be much better to produce an ajcore file and just point to it, or use some other log.
I agree we should make better use of ajcore files. However they will be times when, due to a SecurityManager, the weaver does not have access to the disk and all data will still need to be sent to stderr. What other log do you suggest?
I would suggest: 1) try to write an ajcore file 2) failing that, try to use java.util.logging to log the information at an error level 3) failing that, writing to System.error
I have changed the LTW message handler so that it no longer causes an AbortException when an error is issued. My original intention was to fail the loading of the class concerned but this doesn't happen because the exception is caught somewhere else in weaver/loadtime and it may not be desirable anyway. This should result in fewer "trouble in: ..." type messages where there is actually no problem with weaving. I have opened Bug 155033 "Use ajcore for LTW problems" to look at a more appropriate method of information capture.
I ran into a case where the new code still dumps a spectacular amount of data to the console by dumping bytecode for each class, this with a very recent dev build. I reran with stdout and stderr redirected and have 2 megs of output from startup. This is the kind of scenario that would be greatly improved with ajcore files! In this case, it was a circularity error from some test advice (which was obscured badly by the obscure message and the volumes of bytecode dumped): [PolicyClassLoader@13631582] error at glassbox\monitor\AbstractMonitor.aj:115::0 can't determine precedence between two or more pieces of advice that apply to t he same join point: method-execution... [PolicyClassLoader@13631582] abort trouble in: ...
Fix available in aspectj-DEVELOPMENT-20060824191234.jar.
