The rename conf/log4j.xml to conf/jboss-log4j.xml certainly helps with
the basic app local logging configuration conflicts. The bigger question
is the relationship between the Log4jService and the log4j-rs.sar
created for the Log4jRepositorySelector. Its possible they could be
merged into a more general deployment level log factory service. That is
what needs to be done for jboss5. For 4.2 both changes have value. Its
just a question of if they should be merged, and how this relates to the
existing commons logging issue I'm looking at in the context of the
tomcat filtering. I'll look at how the Log4jRepositorySelector when
using commons logging in a deployment.
Dimitris Andreadis wrote:
Can we first discuss the implications that Scott described for jboss
components using commons logging:
(from
http://jira.jboss.com/jira/browse/JBAS-1853
<
http://jira.jboss.com/jira/browse/JBAS-1853> )
"The next level of isolation is to actually create a unique
LoggerRepository for use by the jboss Logger in the Log4jService. The
concern is that components like jgroups, hibernate, tomcat, etc. using
commons logging will fail to pickup the Log4jService LoggerRepository.
We probably need to configure commons logging as well from the
Log4jService with a flag that can disable this."