You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "David Sean Taylor (JIRA)" <je...@portals.apache.org> on 2009/05/01 17:50:30 UTC

[jira] Assigned: (JS2-972) commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j

     [ https://issues.apache.org/jira/browse/JS2-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Sean Taylor reassigned JS2-972:
-------------------------------------

    Assignee: Vivek Kumar  (was: Ate Douma)

> 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: Vivek Kumar
>            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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org