[
https://issues.apache.org/jira/browse/JS2-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701854#action_12701854
]
Woonsan Ko commented on JS2-972:
--------------------------------
FYI, I met another exception with the unit tests after upgrading spring
framework to 2.5.6 locally:
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at
org.springframework.core.io.support.PropertiesLoaderSupport.<init>(PropertiesLoaderSupport.java:46)
at
org.apache.jetspeed.components.JetspeedBeanDefinitionFilter.<init>(JetspeedBeanDefinitionFilter.java:106)
at
org.apache.jetspeed.components.test.AbstractSpringTestCase.getBeanDefinitionFilter(AbstractSpringTestCase.java:81)
at
org.apache.jetspeed.components.test.AbstractSpringTestCase.setUp(AbstractSpringTestCase.java:48)
at junit.framework.TestCase.runBare(TestCase.java:125)
<SNIP>
So, we need jcl-over-slf4j library anyway because spring core itself depends on
commons-logging.
> 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]
