Community
Participate
Working Groups
I'm using AspectJ 1.8.11 with LoadTimeWeaving. I have added the aspectjweaver.jar to the startup parameters: -javaagent:c:/dev/Java/aspectj1.8/lib/aspectjweaver.jar AspectJ is properly loaded and indeed is weaving my classes as desired/expected. However, any weaveinfo data that it is producing is being logged as an "Error" by my container as it is being written to the stderr stream instead of the stdout: 2016-10-06 13:31:40,310 ERROR [STDERR] [UnifiedClassLoader3@333cf5e3] weaveinfo Join point 'method-call(business.impl.BusinessContext business.ejb3.ManagerBean.getBusinessContext(business.BusinessContextInfo))' in Type 'business.ejb3.ManagerBean' (ManagerBean.java:112) advised by afterThrowing advice from 'common.security.logger.AccessDeniedLoggerAspect' (AccessDeniedLoggerAspect.java) According to Andy Clement: Looking at the WeavingAdaptor, the code says: protected void createMessageHandler() { messageHolder = new WeavingAdaptorMessageHolder(new PrintWriter(System.err)); So all messages sent to that message handler will go to System.err, regardless of severity. That seems a bit crappy. I guess presumably it was done to avoid messages messing up whatever your app was doing on System.out (possibly even just to make testing easier - look for app output on System.out and look for weaver output on System.err). It would be better to have the output of the weaver user configurable. At the moment, all my log messages show up as ERROR instead.
> I guess presumably it was done to avoid messages messing up whatever your app was doing on System.out (possibly even just to make testing easier - look for app output on System.out and look for weaver output on System.err). Yup. If it is made naively made configurable and you flip it to System.out, that would mean real errors also go to System.out. I suspect that is not what you want.
(In reply to Andrew Clement from comment #1) > > I guess presumably it was done to avoid messages messing up whatever your app was doing on System.out (possibly even just to make testing easier - look for app output on System.out and look for weaver output on System.err). > > If it is made naively made configurable and you flip it to System.out, that > would mean real errors also go to System.out. I suspect that is not what you > want. I understand that reasoning, but by the same token, when weave information is enabled, the weaver prints out a lot of detailed information all to stderr, and my log file quickly becomes polluted with essentially debug information. I have no issues with weave errors being output to StdErr, but anything else should at least be configurable, such that I can potentially use a logging subsystem to redirect them to a different file. Right now, I am running AJ in a WildFly 10 container, but all the AJ logs show up as ERROR in my server.log which freaks a lot of people out (ops, QA, etc) who do not understand why there are these error traces being generated.
I do understand your problem. I'm just commenting that currently you choose a destination for that message handler as a whole - it does not differentiate with 'errors here' and 'other output here'. I need to decide whether to do the 'quick fix' and have it configurable so everything goes to one or the other, or make a much more fundamental change that allows you to specify different destinations for errors vs infos/warnings.
