[
https://issues.jboss.org/browse/AS7-3172?page=com.atlassian.jira.plugin.s...
]
David Lloyd resolved AS7-3172.
------------------------------
Fix Version/s: (was: 7.1.0.Final)
Resolution: Rejected
Your summary is a bit misleading. The issue here is that the java.util.logging framework
levels run like this: SEVERE/WARNING/INFO/CONFIG/FINE/FINER/FINEST. However, the more
traditional log4j-style levels run like this: FATAL/ERROR/WARN/INFO/DEBUG/TRACE.
There isn't one single proper mapping from one to the other. Thus things which use
JUL or log4j are logged preserving their original levels (this is important because things
like the JDK and third-party frameworks and libraries may document the level at which
messages are logged).
That said, all of our (JBoss) projects should be using JBoss Logging at this point, which
means log4j-style levels. If any JBoss project is logging using a JUL style level in AS7,
a specific issue should be raised in each project which does so. The project should
either be converted to use JBoss Logging always as a dependency, or to use
maven-shade-plugin or similar to fold the JBoss Logging classes into that project.
Logging incosistency "WARN" vs "WARNING"
----------------------------------------
Key: AS7-3172
URL:
https://issues.jboss.org/browse/AS7-3172
Project: Application Server 7
Issue Type: Bug
Components: Logging
Affects Versions: 7.1.0.CR1
Reporter: Radoslav Husar
Assignee: James Perkins
Priority: Minor
Labels: usability
AS7 internally logs as warn like this
{noformat}
12:24:10,959 WARNING
[org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (MSC service thread
1-11) Channel Muxer already has a default up handler installed
(org.jboss.as.clustering.jgroups.ClassLoaderAwareUpHandler@f5ad7f4) but now it is being
overridden
{noformat}
but projects like Infinispan end up logging
{noformat}
12:28:22,463 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher]
Problems unmarshalling remote command from byte buffer: org.infinispan.CacheException:
Cache manager is either starting up or shutting down but it's not interrupted, so type
(id=74) cannot be resolved.
{noformat}
and this is inconsistent and is a usability issue for people analying logs (like
myself).
How is this handled, what can be done here?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira