With the move to commons logging 1.1, there are incompatibilities showing up when users include older configurations that refer to the obsolete Log4jFactory class. The problem is the result of having container classes initialize their logging in the context of the web application class loader. A user facing this problem went through the exercise of statically initializing the Log instance by loading the Log instance of the following classes during the tomcat deployer startup with its class loader established:
org.apache.jasper.compiler.Compiler
org.apache.catalina.core.ContainerBase
org.apache.tomcat.util.digester.Digester
org.apache.jasper.EmbeddedServletOptions
org.apache.jasper.compiler.JDTCompiler
org.apache.jasper.JspCompilationContext
org.apache.jasper.compiler.JspConfig
org.apache.jasper.compiler.JspReader
org.apache.jasper.compiler.JspRuntimeContext
org.apache.jasper.servlet.JspServlet
org.apache.jasper.servlet.JspServletWrapper
org.apache.catalina.session.ManagerBase
org.apache.jasper.compiler.SmapUtil
org.apache.catalina.core.StandardContext
org.apache.catalina.session.StandardManager
org.apache.jasper.compiler.TldLocationsCache
org.apache.jasper.xmlparser.UTF8Reader
The problem with allowing for lazy initialization in the context of a web app class loader is the use of the TCL logic. Finding web app commons-logging.properties referring to the older older commons logging classes from a LogFactory that has been loaded by the tomcat deployer service class loader is what is causing the problem.
Obfuscating the commons logging classes under an org.jboss.apache.* prefix won't help either as the commons-logging.properties still ends up conflicting. We need to fix the web container logging to the embedding code class loader. The question is whether this is a general change that should be introduced into the tomcat codebase (or jbossweb) rather than something that is done on top.
