[GRADLE-1451] java.lang.ClassCastException Created: 21/Mar/11  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.0
Fix Version/s: None

Type: Bug
Reporter: Anton Vorotynsev Assignee: Unassigned
Resolution: Won't Fix Votes: 0


 Description   

Just installed gradle-1.0-milestone-1 and tried to confirm the installation by running gradle -v. Got the following error:
C:\Documents and Settings\AVorotyntsev>gradle -v

FAILURE: Build aborted because of an internal error.

  • What went wrong:
    Build aborted because of an unexpected internal error. Please file an issue at:
    http://www.gradle.org.
  • Try:
    Run with --debug option to get additional debug info.
  • Exception is:
    java.lang.ClassCastException: org.slf4j.impl.Log4jLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext
    at org.gradle.logging.internal.Slf4jLoggingConfigurer.doFailsafeConfiguration(Slf4jLoggingConfigurer.java:67)
    at org.gradle.logging.internal.Slf4jLoggingConfigurer.configure(Slf4jLoggingConfigurer.java:60)
    at org.gradle.logging.internal.DefaultLoggingConfigurer.configure(DefaultLoggingConfigurer.java:34)
    at org.gradle.logging.internal.LoggingSystemAdapter.setLevel(LoggingSystemAdapter.java:55)
    at org.gradle.logging.internal.LoggingSystemAdapter.on(LoggingSystemAdapter.java:42)
    at org.gradle.logging.internal.DefaultLoggingManager$StartableLoggingSystem.start(DefaultLoggingManager.java:166)
    at org.gradle.logging.internal.DefaultLoggingManager.start(DefaultLoggingManager.java:56)
    at org.gradle.logging.internal.DefaultLoggingManager.start(DefaultLoggingManager.java:31)
    at org.gradle.launcher.CommandLineActionFactory$WithLoggingAction.execute(CommandLineActionFactory.java:208)
    at org.gradle.launcher.CommandLineActionFactory$WithLoggingAction.execute(CommandLineActionFactory.java:193)
    at org.gradle.launcher.Main.execute(Main.java:55)
    at org.gradle.launcher.Main.main(Main.java:40)
    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:597)
    at org.gradle.launcher.ProcessBootstrap.runNoExit(ProcessBootstrap.java:46)
    at org.gradle.launcher.ProcessBootstrap.run(ProcessBootstrap.java:28)
    at org.gradle.launcher.GradleMain.main(GradleMain.java:24)

 Comments   
Comment by Adam Murdoch [ 21/Mar/11 ]

Have you added any jars to $gradleHome/lib? This looks like a conflict between logback-classic.jar, which should be included in the distribution, and slf4j-log4j.jar, which should not.

Comment by Andrew Pietsch [ 14/May/11 ]

I'm getting this too with 0.9.2. After a clean download and install my $GRADLE_HOME/lib directory contains slf4j-api-1.6.1.jar and jul-to-slf4j-1.6.1.jar. Is this incorrect then?

Comment by Andrew Pietsch [ 14/May/11 ]

Found the issue on my machine. Adding the JVM option -verbose:class showed that gradle was picking up older versions from /Library/Java/Extensions. Note to self: don't look under /Library/Java/Home/lib/endorsed or ext on the mac. No idea what installer/application put it there.

Comment by Tom Howard [ 10/Sep/12 ]

This is also happening on OS X for a small group of Aussies with AUSkey (https://www.auskey.abr.gov.au/Homepage.aspx?Task=09b54592-01d5-4b5e-84eb-d80cd46b6889&NavGraph=Home&View=HomeView&pid=71&js=1) installed.

AUSKey places slf4j-log4j12-1.5.8.jar and slf4j-api-1.5.8.jar in /Library/Java/Extensions/

Workaround:
export JAVA_OPTS="-Djava.ext.dirs="

you then should be able to run gradle (it worked for me)

Comment by Bach K [ 14/May/15 ]

@Tom Howard thank you for the tip couple years later!
Bloody AUSKey unbelievable! a dodgy piece of software.

Comment by Matthew Dierker [ 20/Feb/16 ]

Woooow. Sorry to necro an old issue, but wanted to say thanks for the /Library/Java/Extensions/ tip. We spent 30 minutes debugging why this was happening at a hackathon, and this issue saved me. Woohoo!

Comment by Jendrik Johannes (Inactive) [ 13/Sep/16 ]

Problem appeared again in the Android Studio context: https://discuss.gradle.org/t/gradle-failed-to-sync-on-android-studio-on-mac/19450

The workaround - export JAVA_OPTS="-Djava.ext.dirs=" - does not work anymore with the daemon enabled.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 11:55:50 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.