[
https://issues.jboss.org/browse/AS7-5422?page=com.atlassian.jira.plugin.s...
]
James Perkins commented on AS7-5422:
------------------------------------
Notes to add from dmlloyd:
<dmlloyd> here's another enhancement idea that might help
<dmlloyd> if the deployment logging config contains no appenders/handlers, then one
should implicitly be added at the root logger which forwards the message to the main log
context
<dmlloyd> this is to avoid the case where someone unknowingly brings in a stowaway
log4j.properties in some JAR which causes all logs to disappear
<dmlloyd> I think we might need a helper API to do it efficiently though...
Logging configuration DUP should be more deterministic
------------------------------------------------------
Key: AS7-5422
URL:
https://issues.jboss.org/browse/AS7-5422
Project: Application Server 7
Issue Type: Enhancement
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
Notes from [~kconner]:
The findConfigFile method does a recursive search of the resource, looking for the
configuration files, but there seems to be a couple of problems with this
- the order of the search may be dependent on the platform as VFS seems
to rely on the filesystem order (not classpath) so it may not be
deterministic across platforms.
- any log4j.xml/log4j.properties/jboss-log4j.xml will overwrite the
previously discovered resource, resulting in the last being chosen.
I came across this while debugging some strange behaviour when deploying
drools-guvnor.war into EAP 6. What I discovered is that this loop first identified the
top most resource (/content/drools-guvnor.war/WEB-INF/classes/log4j.xml) but then
overwrote it with an embedded one
(/content/drools-guvnor.war/WEB-INF/lib/webdav-servlet-2.0.jar/log4j.xml) but it
doesn't appear as if this method has a well defined behaviour.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira