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/
