It's hard to say - there are quite a few logging changes since M1. It might relate to the fact that we've switched to using JDK logging from log4j at the core, so perhaps something that was happening all along only just now has a visible effect.
Unfortunately I cannot spend more time on this issue, so for now I will continue development on JBoss 6.0.0.M1 and come back to the problem when JBoss 6 is in beta or nearing GA.
Thank you very much for your help on this.
A quick glance at the source code of Spring's TransactionSynchronizationManager shows that it uses Apache commons LogFactory to get hold of the logger.
Would it be possible for you to get us some diagnostic logs from your M2 (and maybe even M1) instances where your application is deployed. All you have to do is add the following system property in the JAVA_OPTS section of run.conf (or run.bat.conf for Windows):
This is expected to print out low level debug messages which might give us a hint on how the logging is being configured. Post (or attach to this thread) the output from your console from M2 (and maybe even from M1, for comparison).
Alternately, if it's possible, maybe you could attach to this thread, a simple app which reproduces this issue?
Yes, I would be more than happy to attach the logs for this. I will do it ASAP today. Thank you for taking the time to look at this.
OK, I'm attaching the two log files.
Thank you for providing those logs.
The log file for jBoss 6.0.0.M2 does not contain the diagnostic information... For some reason the startup option does nothing on M2.
Turns out, 6.0.0.M2 does not ship commons-logging.jar and instead ships jcl-over-slf4j.jar which contains the org.apache.commons.logging.LogFactory. And this implementation in jcl-over-slf4j.jar conveniently ignores that system property. Infact, this implementation doesn't have much in it.
Let's see if those logs provide any other informative details as to what might be causing those duplicate logging and the non-supression of TRACE logs (might have something to do with the slf4j, not sure).
P.S: Ah man, so many wrappers around a (supposed to be) simple logging!
Please let me know if there is anything I can do to help.
I really don't think it's the log facade which does this - I don't see how it could be possible.
If I had a jar which, when deployed, reproduces the problem, I could probably figure it out though.
OK, it took some time to get this together hence the late reply. But attached you will find a .war you should be able to drop into a default jboss 6 M2 distribution to duplicate the issue. Just need to remove the <level name="INFO"/> line in the console handler from jboss-logging.xml.
The trace statements will just start appearing in the logs after server startup do to the background jBPM job executor that is running.
Edit: Oops, sorry I just tried to upload it but it is too large do to all the Spring and jBPM libraries I have in my application. It's 26MB in size. David, I am attempting to email it to you instead.
Was this issue resolved?