logging too verbose

[starksm64]

The tm logging levels are too verbose for our defaults. None of these message should be at INFO level as they don't conform to the logging level usage and should not be showing up on the console:

10:54:48,466 INFO [arjLogger] Periodic recovery - second pass <Fri, 3 Nov 2006 10:54:48>
10:54:48,467 INFO [arjLogger] AtomicActionRecoveryModule: Second pass
10:54:48,467 INFO [txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_6] - TORecoveryModule - second pass
10:54:48,467 INFO [loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.secondpass] Local XARecoveryModule - second pass
10:56:48,486 INFO [arjLogger] Periodic recovery - first pass <Fri, 3 Nov 2006 10:56:48>
10:56:48,486 INFO [arjLogger] StatusModule: first pass
10:56:48,487 INFO [txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_3] - TORecoveryModule - first pass
10:56:48,487 INFO [loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.firstpass] Local XARecoveryModule - first pass

See http://wiki.jboss.org/wiki/Wiki.jsp?page=UsageOfLoggingLevels

[marklittle]

Just looking at the wiki page:

INFO Lifecycle low volume, e.g. "Bound x into jndi", things that are of interest to a user

These are of interest to the user, based on past experience of TS embedded in a range of application servers. So it's arguable whether or not INFO is appropriate. However, ignoring that, you can control the amount of logging from the recovery manager (which is what is generating these messages) and throttle it back. That would be one approach to reducing the amount of information. Alternatively, I assume that you'd expect these to be set at TRACE?

I'm trying to figure out the best approach for AS+TS that doesn't compromise TS stand-alone, where existing users expect these messages to come out on INFO.

[starksm64]

Background events are not something we want on the console(INFO). Just filtering them out is not something we want to do either as then even the server.log (which defaults to DEBUG level) would not have this info. Generally such background processing is a TRACE level event in terms of the jbossas levels. We could live with DEBUG though.

Differing views on logging levels is the bane of all logging frameworks. In the absence of mechanism to map a given (category,level) pair onto a (category,jbossas-level) I don't know how to reconcile this. Can we create a org.jboss.logging.LoggerPlugin that bridges between the arjuna logging framework and the jbossas framework?

[marklittle]

Background events are not something we want on the console(INFO). Just filtering them out is not something we want to do either as then even the server.log (which defaults to DEBUG level) would not have this info. Generally such background processing is a TRACE level event in terms of the jbossas levels. We could live with DEBUG though.

I'll take a look and see what the easiest solution is short-term.

Differing views on logging levels is the bane of all logging frameworks. In the absence of mechanism to map a given (category,level) pair onto a (category,jbossas-level) I don't know how to reconcile this. Can we create a org.jboss.logging.LoggerPlugin that bridges between the arjuna logging framework and the jbossas framework?

We probably already have that capability. We don't access the logger implementation directly, but go through a plugin framework. It may be possible to have a plugin specifically for AS that does the mapping transparently to TS. That may even be the easiest short-term solution!

[starksm64]

Its been a todo to merge the jboss and arjuna logging to finally add i18n support, and John M had been asking about this from the ON perspective as well. Maybe that needs to be done as part of this integration as well.

[marklittle]

I'll check the current issue first and maybe we can put the logging merge as a background/concurrent task in case it looks like delaying the release?

[starksm64]

Even the current issue won't stop the initial beta, so whatever you want to do.

[marklittle]

OK, checked. It certainly looks to me like we could add a logger specifically for AS into TS that would do the on-the-fly translation of INFO to TRACE. It would have to be a global translation, i.e., all INFO becomes TRACE, but then I suspect that the vast majority of what we're putting out on INFO you'd want to come out on TRACE when running in AS anyway. I'm out SCUBA diving next week, so I'll have a word with the team and see what's possible.

[marklittle]

Even the current issue won't stop the initial beta, so whatever you want to do.

OK, not a problem. I'll have a word with John M. when I get back about the long term strategy w.r.t. logging. Thanks.

[dimitris]

Is there any input on this? JBossTS 4.2.2 is configured in JBossAS 4.2, as well.

[marklittle]

This has been fixed for AS 5.0. If you want a patch for 4.2 we can look into that.

[dimitris]

Yes we need to fix this.

How it was fixed for JB5? I'm using the same binaries from the repository.

[dimitris]

JIRA task
http://jira.jboss.com/jira/browse/JBTM-20

[brian.stansberry]

Resurrecting an old thread. Seems the JBTM-20 fix is leading to some issues, since there are discrepancies between the com.arjuna version of Log4JLogger and the forked commons-logging version the AS was using before JBTM-20 was done. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=129207

[sriswasadmin]

Hi All,
Where can i get patch for this issue.. i am using jboss4.3..

Thanks.