Details
-
Bug
-
Status: Closed
-
Blocker
-
Resolution: Fixed
-
2.2.0
-
None
Description
This issue is foremost the same as PLUTO-553, so I won't repeat the description and arguments given there.
However, for Jetspeed the migrating to slf4j requires a bit more changes than merely changing the logger api and maven dependencies fixing.
Note: over the weekend and today I've already done these locally and tested it successfully on both Tomcat and Websphere (6.1.0.9)
- Other (third party) dependencies relying on using commons-logging directly
Examples of these are commons-digester, commons-betwixt and the spring-ojb module.
For these artifacts, the commons-logging api simply needs to be present at runtime.
Luckily, slf4j provides the jcl-over-slf4j jar for exactly this purpose: it provides the commons-logging api but will redirect any usage to leverage slf4j under the hoods.
Jetspeed therefore will have to use this jcl-over-slf4j jar to "fix" these commons-logging usages.
Note: this obviously requires us to exclude any other dependency on commons-logging in the maven poms to prevent api namespace clashes at runtime.
- Explicit Commons Logging functionality used within Jetspeed
The ToolsLogger interface was created to "bridge" Maven Log interface to Commons Logging so that Jetspeed components could be invoked from a Maven plugin while directing their log output through the Maven log.
Implementations of these ToolsLogger interface, CommonsToolsLogger.java and CommonsLogToolsLogger.java now need to be redefined and reimplemented to "bridge" to SLF4J
- jetspeed-webapp-logging/apa-webapp-logging (see also:
JS2-508)
The jetspeed-webapp-logging component has been created long time ago to support "isolated" webapplication log management on certain webservers like Websphere and others like JBoss.
The issue solved by this component was the inability to use both commons-logging and log4j within a webapplication on such webservers properly with as result that log management couldn't be managed and configured locally per webapplication.
However, by migrating to slf4j (+log4j) this problem is "resolved" automatically, which I've already tested successfully on Websphere (not yet on JBoss).
The only requirement to get this working is to use a PARENT_LAST (or CHILD_FIRST) webapplication classloader configuration.
As this is "standard" on Tomcat and for jetspeed required anyway, Jetspeed, nor any other web/portlet application using slf4j, will require the jetspeed-webapp-logging component anymore.
Therefore, although we already were in the process of moving jetspeed-webapp-logging to Portals Application (apa-webapp-logging), I think we can simply "drop" this component, also from APA, after the slf4j migration!
I intend to commit the outstanding changes for this migration to slf4j soon, right after the migration for Pluto (PLUTO-553).