Issue 150 in maven-alfresco-archetypes: commons-logging / slf4j / commons discovery - Non fatal Classloading issue when Axis (in the alfresco.war) starts up in Tomcat7 maven plugin

[maven-alfres...@googlecode.com]

Status: Accepted
Owner: colum...@gmail.com
Labels: Type-Defect Priority-Medium Milestone-Release-sdk-unscheduled

New issue 150 by colum...@gmail.com: commons-logging / slf4j / commons
discovery - Non fatal Classloading issue when Axis (in the alfresco.war)
starts up in Tomcat7 maven plugin
http://code.google.com/p/maven-alfresco-archetypes/issues/detail?id=150

What steps will reproduce the problem?

For the AMP archetype:
1.mvn clean install -Pamp-to-war,run
2.At the end end of the Alfresco (successful) startup, the following
exception is thrown when loading the Axis servlet:

SEVERE: Servlet /alfresco threw load() exception
org.apache.commons.discovery.DiscoveryException: Class
org.apache.commons.logging.impl.SLF4JLogFactory does not implement
org.apache.commons.logging.LogFactory
at
org.apache.commons.discovery.tools.ClassUtils.verifyAncestory(ClassUtils.java:180)
at
org.apache.commons.discovery.tools.SPInterface.verifyAncestory(SPInterface.java:201)
at
org.apache.commons.discovery.tools.SPInterface.newInstance(SPInterface.java:195)
at
org.apache.commons.discovery.tools.DiscoverClass.newInstance(DiscoverClass.java:579)
at
org.apache.commons.discovery.tools.DiscoverSingleton.find(DiscoverSingleton.java:418)
at
org.apache.commons.discovery.tools.DiscoverSingleton.find(DiscoverSingleton.java:378)
at org.apache.axis.components.logger.LogFactory$1.run(LogFactory.java:45)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.axis.components.logger.LogFactory.getLogFactory(LogFactory.java:41)
at
org.apache.axis.components.logger.LogFactory.<clinit>(LogFactory.java:33)
at
org.apache.axis.transport.http.AxisServletBase.<clinit>(AxisServletBase.java:58)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:374)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:138)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1088)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5033)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5317)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

3. Alfresco works, but (most likely, not tested) Axis won't.

What is the expected output? What do you see instead?
No exceptions, Axis working.

More investigation:
We clearly have a classloading issue. I tried to remove some of the
commons-logging stuff following some posts on not having two
commons-logging versions on the classpath, but unsuccessfully. Maybe could
also be related to slf4j itself
(https://confluence.atlassian.com/pages/viewpage.action?pageId=227414216),
not entirely sure at this time.



--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[maven-alfres...@googlecode.com]

Updates:
Labels: -Milestone-Release-sdk-unscheduled Milestone-Release-sdk-1.1.1

Comment #1 on issue 150 by colum...@gmail.com: commons-logging / slf4j /

commons discovery - Non fatal Classloading issue when Axis (in the
alfresco.war) starts up in Tomcat7 maven plugin
http://code.google.com/p/maven-alfresco-archetypes/issues/detail?id=150

(No comment was entered for this change.)

[maven-alfres...@googlecode.com]

Comment #2 on issue 150 by haas...@gmail.com: commons-logging / slf4j /

commons discovery - Non fatal Classloading issue when Axis (in the
alfresco.war) starts up in Tomcat7 maven plugin
http://code.google.com/p/maven-alfresco-archetypes/issues/detail?id=150

i managed to get rid of the exception by adding the bridge between commons
logging and slf4j as dependency in the pom of my amp project:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.5.11</version>
</dependency>

@see http://www.slf4j.org/legacy.html#jclOverSLF4J

[maven-alfres...@googlecode.com]

Comment #3 on issue 150 by bulat.ya...@gmail.com: commons-logging / slf4j /

commons discovery - Non fatal Classloading issue when Axis (in the
alfresco.war) starts up in Tomcat7 maven plugin
http://code.google.com/p/maven-alfresco-archetypes/issues/detail?id=150

This worked for me as well, thanks!

[maven-alfres...@googlecode.com]

Updates:
Labels: -Milestone-Release-sdk-1.1.1 Milestone-Release-sdk-1.1.2

Comment #4 on issue 150 by colum...@gmail.com: commons-logging / slf4j /

commons discovery - Non fatal Classloading issue when Axis (in the
alfresco.war) starts up in Tomcat7 maven plugin
http://code.google.com/p/maven-alfresco-archetypes/issues/detail?id=150

You guys Rock!

I will look to make sure this is added both to the -Pamp-to-war profile
(for the AMP) and to the -Prun profile (for the all-in-one)

[maven-alfres...@googlecode.com]

Updates:
Status: Fixed

Comment #5 on issue 150 by colum...@gmail.com: commons-logging / slf4j /

commons discovery - Non fatal Classloading issue when Axis (in the
alfresco.war) starts up in Tomcat7 maven plugin
http://code.google.com/p/maven-alfresco-archetypes/issues/detail?id=150

This issue was closed by revision r732.