commons-logging unsuited for cross-context webapplication invocation usage -
migrating to slf4j
-----------------------------------------------------------------------------------------------
Key: JS2-972
URL: https://issues.apache.org/jira/browse/JS2-972
Project: Jetspeed 2
Issue Type: Bug
Components: Components Core
Affects Versions: 2.2.0
Reporter: Ate Douma
Assignee: Ate Douma
Priority: Blocker
Fix For: 2.2.0
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).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
