groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: java.lang.LinkageError: loader constraint violation in interface itable
Date Tue, 18 Aug 2015 07:40:52 GMT
Am 18.08.2015 03:53, schrieb William Markito:
> Hi folks,
>
>    Any recommendations for the following problem ? I'm not sure it's a
> problem on Geode implementation..
>
> Thanks!
>
> ---- Groovy Code --
>
> @GrabResolver(name='asf-snapshots', root="https://repository.apache.org/content/repositories/snapshots")
> @Grapes(
>          @Grab(group="org.apache.geode", module ="gemfire-core", version ="1.0.0-incubating-SNAPSHOT")
> )
>
> importcom.gemstone.gemfire.cache.client.ClientCache
> importcom.gemstone.gemfire.cache.client.ClientCacheFactory
>
>
> cache =newClientCacheFactory()
>          .addPoolLocator("localhost",10334)
>          .create();
>
> -----
> ------  Exception
>
> Caught: java.lang.LinkageError: loader constraint violation in interface
[...]

basically it means the bootloader is loading javax.management classes 
and the RootLoader does so as well.. for the same classes. RootLoader is 
a child of the bootloader and is normally supposed to redirect request 
to its parent for class requests and only react if the parent cannot. 
Now RootLoader violates that constraint on purpose and in most cases 
this is fine... as long as no normal java classes are involved with that.

This means the configuration for RootLoader contains a path, that also 
includes javax.management classes, that duplicate the ones from the jdk. 
That should not be the case and they should be removed. If you could 
find out where those come from, it would help a lot. Or are you simply 
using the default distribution of Groovy? If yes, then we might have to 
remove a jar in there. That would fix the issue I think. If of course 
those classes come from gemfire I would argue gemfire is doing something 
wrong here. Because normally RootLoader is used to add those jars to.

A @GrabExclude could be used if those classes are pulled in through a 
dependency of gemfire-core (in that case we should check if the 
dependency is optional)

As an alternative you could try to use 
@GrabConfig(systemClassLoader=true) inside the @Grapes. This will force 
the Gemfire classes being loaded by the system loader instead, bypassing 
the issue above maybe.

bye blackdrag


> itable initialization: when resolving method
> "com.gemstone.gemfire.internal.cache.control.InternalResourceManager$DummyMemoryPoolMXBean.getObjectName()Ljavax/management/ObjectName;"
> the class loader (instance of org/codehaus/groovy/tools/RootLoader) of
> the current class,
> com/gemstone/gemfire/internal/cache/control/InternalResourceManager$DummyMemoryPoolMXBean,
> and the class loader (instance of <bootloader>) for interface
> java/lang/management/PlatformManagedObject have different Class objects
> for the type javax/management/ObjectName used in the signature
> [info 2015/08/17 18:36:43.352 PDT <Distributed system shutdown hook>
> tid=0xe] VM is exiting - shutting down distributed system
> java.lang.LinkageError: loader constraint violation in interface itable
> initialization: when resolving method
> "com.gemstone.gemfire.internal.cache.control.InternalResourceManager$DummyMemoryPoolMXBean.getObjectName()Ljavax/management/ObjectName;"
> the class loader (instance of org/codehaus/groovy/tools/RootLoader) of
> the current class,
> com/gemstone/gemfire/internal/cache/control/InternalResourceManager$DummyMemoryPoolMXBean,
> and the class loader (instance of <bootloader>) for interface
> java/lang/management/PlatformManagedObject have different Class objects
> for the type javax/management/ObjectName used in the signature
>


-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


Mime
View raw message