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" <[email protected]> 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/ > >
