groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anto Aravinth <anto.aravinth....@gmail.com>
Subject Re: java.lang.LinkageError: loader constraint violation in interface itable
Date Tue, 18 Aug 2015 08:49:54 GMT
For me the same issue happens when I use groovy with Selenium. Especially
with FireFoxDriver. If I change that to ChromeDriver it works. Really not
sure why is that the case, the error happens for different classes from the
same jar!
On 18 Aug 2015 09:40, "Jochen Theodorou" <blackdrag@gmx.org> wrote:

> 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