jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Maven Wagon
  • WAGON-60

wagon-webdav fails with commons-logging classloader issues

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 1.0-beta-1
  • Fix Version/s: 1.0-beta-7
  • Component/s: wagon-webdav
  • Labels:
    None
  • Environment:
    maven 2.0.4

Description

I tried it with a build extension and also putting jars in $M2_HOME/lib, but both ways I get classloader issues with commons-logging.

My project uses commons logging and I've seen at least one other report that it can be a problem.

with things in lib:

Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.))
        at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
        at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
        at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
        at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
        at org.apache.commons.httpclient.HttpClient.<clinit>(HttpClient.java:69)
        ... 30 more
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.)
        at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397)
        at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
        ... 34 more
Caused by: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.
        at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:385)

using build extension:

java.lang.ExceptionInInitializerError
        at org.apache.webdav.lib.WebdavSession.getSessionInstance(WebdavSession.java:145)
        at org.apache.webdav.lib.WebdavSession.getSessionInstance(WebdavSession.java:127)
        at org.apache.webdav.lib.WebdavResource.setClient(WebdavResource.java:1273)
        at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1298)
        at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1320)
        at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1408)
        at org.apache.webdav.lib.WebdavResource.<init>(WebdavResource.java:290)
        at org.apache.maven.wagon.providers.webdav.CorrectedWebdavResource.<init>(CorrectedWebdavResource.java:52)
        at org.apache.maven.wagon.providers.webdav.WebDavWagon.openConnection(WebDavWagon.java:139)
        at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143)
        at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:106)
        at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:132)
        at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
        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 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log
        at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:532)
        at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:272)
        at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:246)
        at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:395)
        at org.apache.commons.httpclient.HttpClient.<clinit>(HttpClient.java:69)
        ... 30 more
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log
        at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:416)
        at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:525)
        ... 34 more
Caused by: org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log
        at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:412)
        ... 35 more

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. MSITE-459 More than one version of 'org.apache.commons.logging.Log' visible in the classpath

  • Blocker - Blocks development and/or testing work, production could not run
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Dennis Lundberg added a comment - 12/Aug/06 3:39 PM

A good way to diagnose problems regarding commons-logging and classloading issues is to upgrade the dependency on commons-logging to version 1.1. That version has some great new diagnostics that can be turned on.

You can read more on how to do this in the Commons Logging troubleshooting guide:
http://jakarta.apache.org/commons/logging/troubleshooting.html#How_To_Use_Diagnostic_logging

Show
Dennis Lundberg added a comment - 12/Aug/06 3:39 PM A good way to diagnose problems regarding commons-logging and classloading issues is to upgrade the dependency on commons-logging to version 1.1. That version has some great new diagnostics that can be turned on. You can read more on how to do this in the Commons Logging troubleshooting guide: http://jakarta.apache.org/commons/logging/troubleshooting.html#How_To_Use_Diagnostic_logging
Hide
Permalink
Carlos Sanchez added a comment - 13/Aug/06 11:52 AM

I've be using wagon-webdav as build extension without problems.

Show
Carlos Sanchez added a comment - 13/Aug/06 11:52 AM I've be using wagon-webdav as build extension without problems.
Hide
Permalink
Yuri Schimke added a comment - 13/Aug/06 1:58 PM

I'm assuming its because there are two copies of commons-logging loaded by different extensions or plugins.

Is there somewhere I can put the commons-logging jars so they don't get loaded by extension, plugin or reportingPlugin classloaders that conflict.

Show
Yuri Schimke added a comment - 13/Aug/06 1:58 PM I'm assuming its because there are two copies of commons-logging loaded by different extensions or plugins. Is there somewhere I can put the commons-logging jars so they don't get loaded by extension, plugin or reportingPlugin classloaders that conflict.
Hide
Permalink
Yuri Schimke added a comment - 14/Aug/06 4:00 PM

I deleted ~/.m2/repository and tried it again, its now working. I guess I had a bad jar, or possibly one of the snapshots I had built myself was getting in the way.

Show
Yuri Schimke added a comment - 14/Aug/06 4:00 PM I deleted ~/.m2/repository and tried it again, its now working. I guess I had a bad jar, or possibly one of the snapshots I had built myself was getting in the way.
Hide
Permalink
Ivan S. Dubrov added a comment - 14/Nov/06 11:09 PM

Simple workaround for whom still getting this error. You can SLF4J implementation of Commons Logging interface. Just put jcl104-over-slf4j.jar and slf4j-jdk14.jar (or any other SLF4J backend) from the http://www.slf4j.org/dist/slf4j-1.0.2.zip instead of commons-logging.jar into your maven lib directory.

Show
Ivan S. Dubrov added a comment - 14/Nov/06 11:09 PM Simple workaround for whom still getting this error. You can SLF4J implementation of Commons Logging interface. Just put jcl104-over-slf4j.jar and slf4j-jdk14.jar (or any other SLF4J backend) from the http://www.slf4j.org/dist/slf4j-1.0.2.zip instead of commons-logging.jar into your maven lib directory.
Hide
Permalink
Mark Hobson added a comment - 26/Nov/06 5:23 PM

I just had this error when doing a site:deploy. It was fixed by upgrading from maven-site-plugin to 2.0-beta-5.

Show
Mark Hobson added a comment - 26/Nov/06 5:23 PM I just had this error when doing a site:deploy. It was fixed by upgrading from maven-site-plugin to 2.0-beta-5.
Hide
Permalink
Grant McDonald added a comment - 30/Jun/08 7:27 AM - edited

This is reproducible on maven 2.0.9

This issue appears to relate to how the extension class loader is populated. By having the extension class loader include commons-logging this conflicts where this is also included by the other reactors such as the reporting plugins. From the webdav-wagon pom:

<dependencies>
<dependency>
<groupId>slide</groupId>
<artifactId>slide-webdavlib</artifactId>
<version>2.1</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.0.4</version>
<scope>runtime</scope>
</dependency>

And from the debug output:

[DEBUG] Adding managed dependencies for unknown:wagon-webdav
[DEBUG] org.apache.maven.wagon:wagon-ssh-common:jar:1.0-beta-2
[DEBUG] org.apache.maven.wagon:wagon-ssh-common-test:jar:1.0-beta-2:test
[DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-beta-2
[DEBUG] org.apache.maven.wagon:wagon-provider-test:jar:1.0-beta-2
[DEBUG] junit:junit:jar:3.8.1
[DEBUG] org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-4
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4
[DEBUG] com.bglobal:acore:jar:1.0-SNAPSHOT (selected for null)
[DEBUG] slide:slide-webdavlib:jar:2.1:runtime (selected for runtime)
[DEBUG] commons-httpclient:commons-httpclient:jar:2.0.2:runtime (selected for runtime)
[DEBUG] commons-logging:commons-logging:jar:1.0.3:runtime (selected for runtime)
[DEBUG] jdom:jdom:jar:1.0:runtime (selected for runtime)
[DEBUG] de.zeigermann.xml:xml-im-exporter:jar:1.1:runtime (selected for runtime)
[DEBUG] commons-logging:commons-logging:jar:1.0.3:runtime (removed - nearer found: 1.0.4)
[DEBUG] commons-logging:commons-logging:jar:1.0.4:runtime (selected for runtime)

Show
Grant McDonald added a comment - 30/Jun/08 7:27 AM - edited This is reproducible on maven 2.0.9 This issue appears to relate to how the extension class loader is populated. By having the extension class loader include commons-logging this conflicts where this is also included by the other reactors such as the reporting plugins. From the webdav-wagon pom: <dependencies> <dependency> <groupId>slide</groupId> <artifactId>slide-webdavlib</artifactId> <version>2.1</version> </dependency> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>1.0.4</version> <scope>runtime</scope> </dependency> And from the debug output: [DEBUG] Adding managed dependencies for unknown:wagon-webdav [DEBUG] org.apache.maven.wagon:wagon-ssh-common:jar:1.0-beta-2 [DEBUG] org.apache.maven.wagon:wagon-ssh-common-test:jar:1.0-beta-2:test [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-beta-2 [DEBUG] org.apache.maven.wagon:wagon-provider-test:jar:1.0-beta-2 [DEBUG] junit:junit:jar:3.8.1 [DEBUG] org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-4 [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8 [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 [DEBUG] com.bglobal:acore:jar:1.0-SNAPSHOT (selected for null) [DEBUG] slide:slide-webdavlib:jar:2.1:runtime (selected for runtime) [DEBUG] commons-httpclient:commons-httpclient:jar:2.0.2:runtime (selected for runtime) [DEBUG] commons-logging:commons-logging:jar:1.0.3:runtime (selected for runtime) [DEBUG] jdom:jdom:jar:1.0:runtime (selected for runtime) [DEBUG] de.zeigermann.xml:xml-im-exporter:jar:1.1:runtime (selected for runtime) [DEBUG] commons-logging:commons-logging:jar:1.0.3:runtime (removed - nearer found: 1.0.4) [DEBUG] commons-logging:commons-logging:jar:1.0.4:runtime (selected for runtime)
Hide
Permalink
Fabrice Daugan added a comment - 18/Aug/08 11:20 AM

Also this problem causes an issue in dashboard plugin, since there is no way to constraint commons-logging artifact version inside the extension node.

Show
Fabrice Daugan added a comment - 18/Aug/08 11:20 AM Also this problem causes an issue in dashboard plugin, since there is no way to constraint commons-logging artifact version inside the extension node.
Hide
Permalink
Mick Knutson added a comment - 11/May/09 4:03 PM

I am also having this issue withe the wagon and/or the dashboard. When I comment out the wagon extension, the dashboard runs fine.

When I un-comment the Wagon extension and try to run the dashboard, I get this commons-logging error.

Show
Mick Knutson added a comment - 11/May/09 4:03 PM I am also having this issue withe the wagon and/or the dashboard. When I comment out the wagon extension, the dashboard runs fine. When I un-comment the Wagon extension and try to run the dashboard, I get this commons-logging error.
Hide
Permalink
Lorenzo Bigagli added a comment - 20/Jan/10 12:25 PM - edited

We are having this problem with maven 2.2.1, wagon-webdav 1.0-beta-2, maven-site-plugin:2.1 on mvn site:deploy.

Reverting to maven-site-plugin:2.0 worked around the issue.

I have tried to force using commons-logging:1.1.1, but this is not possible in extensions/reporting plugins.
Don't know if this would fix it, though.
Anybody has an idea what is the exact offending component?

There are quite many others reporting apparently similar problems: maybe this should be reopened and investigated further.

Show
Lorenzo Bigagli added a comment - 20/Jan/10 12:25 PM - edited We are having this problem with maven 2.2.1, wagon-webdav 1.0-beta-2, maven-site-plugin:2.1 on mvn site:deploy. Reverting to maven-site-plugin:2.0 worked around the issue. I have tried to force using commons-logging:1.1.1, but this is not possible in extensions/reporting plugins. Don't know if this would fix it, though. Anybody has an idea what is the exact offending component? There are quite many others reporting apparently similar problems: maybe this should be reopened and investigated further.
Hide
Permalink
Carlos Sanchez added a comment - 20/Jan/10 12:51 PM

reopened per users comments

Show
Carlos Sanchez added a comment - 20/Jan/10 12:51 PM reopened per users comments
Hide
Permalink
David Pilato added a comment - 13/Apr/10 9:48 AM - edited

As Lorenzo said :

We are having this problem with maven 2.2.1, wagon-webdav 1.0-beta-2, maven-site-plugin:2.1 on mvn site:deploy.

Reverting to maven-site-plugin:2.0 worked around the issue.

Same issue for me with maven 2.2.1 and maven-site-plugin:2.1.

Here is the context :
Multimodule project :
A : pom
B : jar
C : war

1) When I run mvn site from A, it doesn't work.
2) When I run mvn install from A, it works.
3) When I run mvn install site from A, it fails during the site phase for module C.
4) When I run mvn install site from C, it works.

It seems that the classpath for the first test includes commons-logging 1.0.4 (or 1.0.6) and commons-logging 1.1.1
For the second test, it uses only commons-logging 1.1.1
The third test add the two libs in classpath so it fails.

Is there a way to force maven to only use commons-logging 1.1.1 (for build, plugins, dependencies, ...) ?

Thanks

Show
David Pilato added a comment - 13/Apr/10 9:48 AM - edited As Lorenzo said :
We are having this problem with maven 2.2.1, wagon-webdav 1.0-beta-2, maven-site-plugin:2.1 on mvn site:deploy. Reverting to maven-site-plugin:2.0 worked around the issue.
Same issue for me with maven 2.2.1 and maven-site-plugin:2.1. Here is the context : Multimodule project : A : pom B : jar C : war 1) When I run mvn site from A, it doesn't work. 2) When I run mvn install from A, it works. 3) When I run mvn install site from A, it fails during the site phase for module C. 4) When I run mvn install site from C, it works. It seems that the classpath for the first test includes commons-logging 1.0.4 (or 1.0.6) and commons-logging 1.1.1 For the second test, it uses only commons-logging 1.1.1 The third test add the two libs in classpath so it fails. Is there a way to force maven to only use commons-logging 1.1.1 (for build, plugins, dependencies, ...) ? Thanks
Hide
Permalink
Dennis Lundberg added a comment - 14/Sep/10 5:49 PM

Fixed in r997128.

To get this to work you need to use the latest version of wagon-webdav-jackrabbit as an extension.

Add the following to the build section of your POM. If you already have a build extension in there for wagon-webdav 1.0-beta-2 you should remove that.

<extensions>
        <extension>
          <groupId>org.apache.maven.wagon</groupId>
          <artifactId>wagon-webdav-jackrabbit</artifactId>
          <version>1.0-beta-7-SNAPSHOT</version>
        </extension>
      </extensions>
Show
Dennis Lundberg added a comment - 14/Sep/10 5:49 PM Fixed in r997128. To get this to work you need to use the latest version of wagon-webdav-jackrabbit as an extension. Add the following to the build section of your POM. If you already have a build extension in there for wagon-webdav 1.0-beta-2 you should remove that.
<extensions>
        <extension>
          <groupId>org.apache.maven.wagon</groupId>
          <artifactId>wagon-webdav-jackrabbit</artifactId>
          <version>1.0-beta-7-SNAPSHOT</version>
        </extension>
      </extensions>

People

  • Assignee:
    Dennis Lundberg
    Reporter:
    Yuri Schimke
Vote (1)
Watch (1)

Dates

  • Created:
    12/Aug/06 3:25 PM
    Updated:
    14/Sep/10 5:56 PM
    Resolved:
    14/Sep/10 5:49 PM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.