Mailing-List: contact users-help@groovy.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@groovy.incubator.apache.org
Message-ID: <55D4C5C9.1050109@gmx.org>
Date: Wed, 19 Aug 2015 20:07:05 +0200
From: Jochen Theodorou <blackdrag@gmx.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: users@groovy.incubator.apache.org
Subject: Re: java.lang.LinkageError: loader constraint violation in interface
 itable
References: 
 <CAK7stcw6UKF-MYxB3Rn=_3vN6_GyGutQ7RPmbmMz1YFqRM4Piw@mail.gmail.com>
 <55D2E184.30000@gmx.org>
 <CAK7stczOegq88yoSFiwkpJXE21k4uDDxeDOGJ5WAER81omL9_Q@mail.gmail.com>
 <55D485A2.7030503@gmx.org>
 <CAK7stcwr+e0AdtxUbhNB0E46KqC4mtWG-PPr-f20e7+T1jmb-g@mail.gmail.com>
In-Reply-To: 
 <CAK7stcwr+e0AdtxUbhNB0E46KqC4mtWG-PPr-f20e7+T1jmb-g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

well... of course one variant is from the rt.jar. But that is no 
problem, unless the classpath for RootLoader is defined to include the 
rt.jar. We need to know the second origin of that class.


I took a look at 
https://repository.apache.org/content/repositories/snapshots/org/apache/geode/gemfire-core/1.0.0-incubating-SNAPSHOT/gemfire-core-1.0.0-incubating-20150813.110411-49.pom 
and I see there a dependency on mx4j 3.0.1 Which sounds supicious to me. 
I checked and the mx4j.jar contains javax.management classes, including 
ObjectName. And it is not optional.

This explains to me why the problem happens in the original version of 
your code. Defining an exclude should in theory take care of it. As for 
the @GrabConfig... I am actually not sure about its position if @Grapes 
is used. I think it should have worked like you tried, but putting it 
inside the @Grapes list (see the second example on 
http://docs.groovy-lang.org/latest/html/api/groovy/lang/GrabConfig.html) 
might be something to try.

As for Selenium with Firefox driver... I would assume it is a similar 
issue... some dependency is pulled in which maybe was originally thought 
as an addition to j2se for limited j2ee usages like mx4j and the class 
loader setup gets broken

bye blackdrag


Am 19.08.2015 17:30, schrieb William Markito:
> According to IntelliJ, in my Groovy project with Geode/GemFire jars, it
> comes from *rt.jar* from the JDK.
>
> /Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/jre/lib/rt.jar!/javax/management/ObjectName.class
>
>
>
> On Wed, Aug 19, 2015 at 6:33 AM, Jochen Theodorou <blackdrag@gmx.org
> <mailto:blackdrag@gmx.org>> wrote:
>
>     Then any idea what jar comes and adds a javax.management.ObjectName ?
>
>     Am 19.08.2015 01:13, schrieb William Markito:
>
>         Thanks Jochen, but even with the system classloader I have the
>         same issue.
>
>         ------------------------------
>         @GrabConfig(systemClassLoader= true)
>         @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();
>
>         region = cache.createClientRegionFactory("myRegion")
>
>         region.put("1","Hello")
>         region.put("2","World")
>
>
>         --------------------
>         Caught: 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
>         [info 2015/08/18 16:11:16.526 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
>         at
>         com.gemstone.gemfire.internal.cache.control.InternalResourceManager.<clinit>(InternalResourceManager.java:469)
>         at
>         com.gemstone.gemfire.internal.cache.GemFireCacheImpl.<init>(GemFireCacheImpl.java:755)
>         at
>         com.gemstone.gemfire.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:667)
>         at
>         com.gemstone.gemfire.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:207)
>         at
>         com.gemstone.gemfire.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:162)
>         at
>         com.gemstone.gemfire.cache.client.ClientCacheFactory$create$0.call(Unknown
>         Source)
>         at HelloWorld.run(HelloWorld.groovy:16)
>         at
>         com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
>
>
>         On Tue, Aug 18, 2015 at 12:40 AM, Jochen Theodorou
>         <blackdrag@gmx.org <mailto:blackdrag@gmx.org>
>         <mailto:blackdrag@gmx.org <mailto: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/
>
>
>
>
>         --
>
>         William Markito Oliveira
>         Enterprise Architect
>         -- For questions about Apache Geode, please write to
>         *dev@geode.incubator.apache.org
>         <mailto:dev@geode.incubator.apache.org>
>         <mailto:dev@geode.incubator.apache.org
>         <mailto:dev@geode.incubator.apache.org>>*
>
>
>
>
>     --
>     Jochen "blackdrag" Theodorou
>     blog: http://blackdragsview.blogspot.com/
>
>
>
>
> --
>
> William Markito Oliveira
> Enterprise Architect
> -- For questions about Apache Geode, please write to
> *dev@geode.incubator.apache.org <mailto:dev@geode.incubator.apache.org>*
>
>


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