Sakai and Log4J

In my digging around with Sakai I came across the fact that the Sakai logging JARs are deployed to tomcat/common, the extra JARs are deployed there are sakai-util-log-dev.jar and log4j-1.2.8.jar. Placing these files in the common classloader means that they are available to both the deployed applications as well as the servlet container (Tomcat) itself. Now often log4j along with commons-logging JARs are placed into the common classloader so that Tomcat (5.5) will use log4j for its own internal logging. If other log4j JARs don't exist in any of the other classloaders all logging will go through the same log4j class and configuration. Applications are still free to provide their own log4j implmenetation along with configuration which should be insulated from the container log4j. This is because the common classloader is checked last (after the webapp and shared ones). Sakai would only need to deploy its logging code to common if it wanted to control the logging of the container as well as it's own logging. Some Sakai log messages may end up in the container logs if any of the Sakai tools log against the servlet context (getServletContext().log(String)). I don't think there is any harm to Sakai by placing the JARs in shared as all that happens is you can't control the container logging. To get Sakai logging working correctly there would also need to have commons-logging in the common classloader, so I'm not convinced that this setup works to control the container logging. As a side note Tomcat ships with a commons-logging-api but this doesn't provide the full logging framework, just enough to get going. Helpful web documents include:

• Logging for Apache Tomcat
• Tomcat 5.5 Classloading
• New Sakai Logging