[
https://issues.apache.org/jira/browse/JS2-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701602#action_12701602
]
Woonsan Ko commented on JS2-972:
--------------------------------
Hi Ate,
I've just run unit tests today for my JS2-976 task.
I instantly met an exception complaining commons-logging stuffs.
-------------------------------------------------------------------------------
Test set: org.apache.jetspeed.cache.TestContentCache
-------------------------------------------------------------------------------
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.126 sec <<<
FAILURE!
testContentCacheByUser(org.apache.jetspeed.cache.TestContentCache) Time
elapsed: 0.086 sec <<< ERROR!
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.springframework.util.ClassUtils.<clinit>(ClassUtils.java:73)
at
org.springframework.core.io.ClassPathResource.<init>(ClassPathResource.java:82)
at
org.springframework.core.io.ClassPathResource.<init>(ClassPathResource.java:64)
at
org.apache.jetspeed.cache.impl.EhCacheConfigResource.afterPropertiesSet(EhCacheConfigResource.java:206)
at
org.apache.jetspeed.cache.impl.EhCacheConfigResource.getInstance(EhCacheConfigResource.java:84)
at
org.apache.jetspeed.cache.TestContentCache.testContentCacheByUser(TestContentCache.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
<SNIP>
I've just investigated the spring source history (ClassUtils.java).
The ClassUtils.java was changed to not statically use LogFactory since June 4,
2008.
And, this changes can be applied since Spring Framework 2.5.5 release.
Therefore, I think it is inevitable to upgrade the version to 2.5.5 or 2.5.6
now.
If there's no objection to upgrade it to 2.5.6 and no commit before I do, I
will do this as soon as possible.
> 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]
