Announcement Announcement Module
Collapse
No announcement yet.
java.lang.LinkageError: loader constraint violation when running grails scripts 2.6.1 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • java.lang.LinkageError: loader constraint violation when running grails scripts 2.6.1

    Doesn't seem to matter what I do - every grails command ends up with the following problem:

    Stack trace:

    Error executing script CreateApp: loader constraint violation: when resolving overridden method "org.apache.xerces.jaxp.SAXParserImpl.getXMLReader ()Lorg/xml/sax/XMLReader;" the class loader (instance of org/codehaus/groovy/grails/cli/support/GrailsRootLoader) of the current class, org/apache/xerces/jaxp/SAXParserImpl, and its superclass loader (instance of <bootloader>), have different Class objects for the type org/xml/sax/XMLReader used in the signature
    java.lang.LinkageError: loader constraint violation: when resolving overridden method "org.apache.xerces.jaxp.SAXParserImpl.getXMLReader ()Lorg/xml/sax/XMLReader;" the class loader (instance of org/codehaus/groovy/grails/cli/support/GrailsRootLoader) of the current class, org/apache/xerces/jaxp/SAXParserImpl, and its superclass loader (instance of <bootloader>), have different Class objects for the type org/xml/sax/XMLReader used in the signature
    at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAX Parser(Unknown Source)
    at org.apache.ivy.util.XMLHelper.newSAXParser(XMLHelp er.java:58)
    at org.apache.ivy.util.XMLHelper.parse(XMLHelper.java :118)
    at org.apache.ivy.util.XMLHelper.parse(XMLHelper.java :94)
    at org.apache.ivy.util.XMLHelper.parse(XMLHelper.java :84)
    at org.apache.ivy.plugins.parser.xml.XmlModuleDescrip torParser$Parser.parse(XmlModuleDescriptorParser.j ava:248)
    at org.apache.ivy.plugins.parser.xml.XmlModuleDescrip torParser.parseDescriptor(XmlModuleDescriptorParse r.java:112)
    at org.apache.ivy.plugins.parser.AbstractModuleDescri ptorParser.parseDescriptor(AbstractModuleDescripto rParser.java:48)
    at org.apache.ivy.core.cache.DefaultRepositoryCacheMa nager$MyModuleDescriptorProvider.provideModule(Def aultRepositoryCacheManager.java:659)
    at org.apache.ivy.core.cache.ModuleDescriptorMemoryCa che.getStale(ModuleDescriptorMemoryCache.java:68)
    at org.apache.ivy.core.cache.ModuleDescriptorMemoryCa che.get(ModuleDescriptorMemoryCache.java:57)
    at org.apache.ivy.core.cache.DefaultRepositoryCacheMa nager.getMdFromCache(DefaultRepositoryCacheManager .java:668)
    at org.apache.ivy.core.cache.DefaultRepositoryCacheMa nager.doFindModuleInCache(DefaultRepositoryCacheMa nager.java:584)
    at org.apache.ivy.core.cache.DefaultRepositoryCacheMa nager.findModuleInCache(DefaultRepositoryCacheMana ger.java:542)
    at org.apache.ivy.plugins.resolver.AbstractResolver.f indModuleInCache(AbstractResolver.java:352)
    at org.apache.ivy.plugins.resolver.ChainResolver.getD ependency(ChainResolver.java:91)
    at org.apache.ivy.core.resolve.IvyNode.loadData(IvyNo de.java:169)
    at org.apache.ivy.core.resolve.VisitNode.loadData(Vis itNode.java:287)
    at org.apache.ivy.core.resolve.ResolveEngine.fetchDep endencies(ResolveEngine.java:696)
    at org.apache.ivy.core.resolve.ResolveEngine.doFetchD ependencies(ResolveEngine.java:781)
    at org.apache.ivy.core.resolve.ResolveEngine.fetchDep endencies(ResolveEngine.java:704)
    at org.apache.ivy.core.resolve.ResolveEngine.getDepen dencies(ResolveEngine.java:576)
    at org.apache.ivy.core.resolve.ResolveEngine.resolve( ResolveEngine.java:237)
    at org.apache.ivy.core.resolve.ResolveEngine$resolve. call(Unknown Source)
    at grails.util.BuildSettings$_getDefaultCompileDepend encies_closure9.doCall(BuildSettings.groovy:293)
    at grails.util.BuildSettings$_getDefaultCompileDepend encies_closure9.doCall(BuildSettings.groovy)
    at grails.util.BuildSettings.getDefaultCompileDepende ncies(BuildSettings.groovy:293)
    at grails.util.BuildSettings.getCompileDependencies(B uildSettings.groovy:278)
    at _GrailsClasspath_groovy$_run_closure8.doCall(_Grai lsClasspath_groovy:130)
    at _GrailsClasspath_groovy$_run_closure8.doCall(_Grai lsClasspath_groovy)
    at _GrailsClasspath_groovy.setClasspath(_GrailsClassp ath_groovy:190)
    at _GrailsClasspath_groovy$_run_closure1.doCall(_Grai lsClasspath_groovy:39)
    at _GrailsEvents_groovy.run(_GrailsEvents_groovy:50)
    at _GrailsEvents_groovy$run.call(Unknown Source)
    at _GrailsClean_groovy$run.call(Unknown Source)
    at _GrailsClean_groovy.run(_GrailsClean_groovy:29)
    at _GrailsClean_groovy$run.call(Unknown Source)
    at _GrailsPlugins_groovy$run.call(Unknown Source)
    at _GrailsPlugins_groovy.run(_GrailsPlugins_groovy:32 )
    at _GrailsPlugins_groovy$run.call(Unknown Source)
    at _GrailsCreateProject_groovy$run.call(Unknown Source)
    at _GrailsCreateProject_groovy.run(_GrailsCreateProje ct_groovy:28)
    at _GrailsCreateProject_groovy$run.call(Unknown Source)
    at CreateApp_.run(CreateApp_:25)
    at CreateApp_$run.call(Unknown Source)
    at gant.Gant.prepareTargets(Gant.groovy:606)
    Error executing script CreateApp: loader constraint violation: when resolving overridden method "org.apache.xerces.jaxp.SAXParserImpl.getXMLReader ()Lorg/xml/sax/XMLReader;" the class loader (instance of org/codehaus/groovy/grails/cli/support/GrailsRootLoader) of the current class, org/apache/xerces/jaxp/SAXParserImpl, and its superclass loader (instance of <bootloader>), have different Class objects for the type org/xml/sax/XMLReader used in the signature

    STS is a clean install on OSX 10.6. Basic eclipse configuration:

    awt.nativeDoubleBuffering=true
    awt.toolkit=apple.awt.CToolkit
    com.atlassian.connector.eclipse.branding.ui.isOnly JiraInstalled=true
    eclipse.application=org.eclipse.ui.ide.workbench
    eclipse.buildId=2.6.1.201105041000-RELEASE
    eclipse.commands=-os
    macosx
    -ws
    cocoa
    -arch
    x86_64
    -showsplash
    -launcher
    /Users/rnorris/springsource/sts-2.6.1.RELEASE/STS.app/Contents/MacOS/STS
    -name
    STS
    --launcher.library
    /Users/rnorris/springsource/sts-2.6.1.RELEASE/STS.app/Contents/MacOS//../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1 .1.2.R36x_v20101019_1345/eclipse_1310.so
    -startup
    /Users/rnorris/springsource/sts-2.6.1.RELEASE/STS.app/Contents/MacOS//../../../plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_ 1400.jar
    -product
    com.springsource.sts.ide
    -keyring
    /Users/rnorris/.eclipse_keyring
    -showlocation
    -vm
    /System/Library/Frameworks/JavaVM.framework
    eclipse.home.location=file:/Users/rnorris/springsource/sts-2.6.1.RELEASE/
    eclipse.launcher=/Users/rnorris/springsource/sts-2.6.1.RELEASE/STS.app/Contents/MacOS/STS
    eclipse.launcher.name=STS
    eclipse.p2.data.area=@config.dir/../p2/
    eclipse.p2.profile=com.springsource.sts.ide
    eclipse.product=com.springsource.sts.ide
    eclipse.startTime=1305917079228
    eclipse.vm=/System/Library/Frameworks/JavaVM.framework
    eclipse.vmargs=-Dosgi.requiredJavaVersion=1.5
    -Xms40m
    -Xmx768m
    -XX:MaxPermSize=256m
    -XstartOnFirstThread


    I've found a couple of promising JIRA items suggesting deleting the ivy cache would help - it didn't.

    Have tried rolling back to grails 1.3.5 as well, and have tried multiple versions of STS to no avail.

  • #2
    Hi,

    Does that same problem occur running the grails commands from the command line? Sounds like a library you depend on is clashing with a base JDK dependency.

    A quick google of mine showed making a couple of changes to BuildConfig can alleviate problems like this, but you may have to know which plugins are interfering and giving rise to the problem. Maybe you already found posts like this:

    http://tapomay.blogspot.com/2010/04/...ounderror.html
    http://grails.1312388.n4.nabble.com/...td1392619.html

    The diagnosis in that first blog post was: It seems that nekohtml has a dependency on xercesImpl that in turn has a dependency on xml-apis.jar that contains the class org/xml/sax/Parser. However this class had already been loaded by some parent class loader from somewhere else.

    Maybe you have a dependency that is also pulling in some other version of xercesimpl.

    If your commands ont he command line work, but not inside STS, that would suggest we are introducing the problem, we'll need a jira for that I think: https://issuetracker.springsource.com/browse/STS

    regards
    Andy
    ---
    Andy Clement

    Comment


    • #3
      It works fine from the command line - I'll hit up JIRA. Thanks.

      Sadly, it's a showstopper for me now.

      These are brand new grails projects, so the only dependencies are the ones required by grails OTB.

      Comment

      Working...
      X