[
https://issues.apache.org/jira/browse/FELIX-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920997#action_12920997
]
Richard S. Hall commented on FELIX-2653:
----------------------------------------
Just some more summary, it appears that the situation is such that we are
getting a request for a class that a bundle shouldn't have. However, as part of
our normal processing of a failed class request we try to determine if we
should implicitly boot delegate if the request was coming from external code.
In this particular scenario we ended up causing the class being requested to be
defined as a byproduct in getEnclosingClass(). Thus, when we get back to the
original class loader, it has already checked for the class and doesn't check
again, so it gets a duplicate definition error. I'm not sure if we can resolve
this in a general way.
> LinkageError caused by duplicate class definition during implicit boot
> delegation
> ---------------------------------------------------------------------------------
>
> Key: FELIX-2653
> URL: https://issues.apache.org/jira/browse/FELIX-2653
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-3.0.4
> Environment: java version "1.6.0_21"
> Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
> Java HotSpot(TM) Server VM (build 17.0-b16, mixed mode)
> Reporter: Sahoo
> Assignee: Richard S. Hall
> Priority: Critical
> Fix For: framework-3.2.0
>
>
> I am seeing linkage errors caused by attempt to load duplicate classes and I
> think it is caused by implicit boot delegation. In our server log, we see the
> following exception stack:
> java.lang.LinkageError: loader (instance of java/net/URLClassLoader):
> attempted duplicate class definition for name: "com/acme/Foo"
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> at com.acme.Foo$Factory.bar(Foo.java:93)
> I tried to trace the execution to find out what causes the class to be
> defined for the first time and with the help of btrace
> (http://projectkenai.com/projects/btrace/), I could obtain the stack and
> relevant information. First time the class is defined, the stack looks like
> this:
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
> java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
> java.net.URLClassLoader.access$000(URLClassLoader.java:58)
> java.net.URLClassLoader$1.run(URLClassLoader.java:197)
> java.security.AccessController.doPrivileged(Native Method)
> java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> org.apache.felix.framework.ModuleImpl.getEnclosingClass(ModuleImpl.java:1570)
> org.apache.felix.framework.ModuleImpl.isClassNotLoadedFromBundle(ModuleImpl.java:1545)
> org.apache.felix.framework.ModuleImpl.doImplicitBootDelegation(ModuleImpl.java:1498)
> org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1452)
> org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:727)
> org.apache.felix.framework.ModuleImpl.access$300(ModuleImpl.java:73)
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1733)
> java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:638)
> org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1599)
> org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:904)
> org.jvnet.hk2.osgiadapter.OSGiModuleImpl$3$1.run(OSGiModuleImpl.java:399)
> java.security.AccessController.doPrivileged(Native Method)
> org.jvnet.hk2.osgiadapter.OSGiModuleImpl$3.loadClass(OSGiModuleImpl.java:395)
> java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:169)
> java.lang.ClassLoader.loadClass(ClassLoader.java:296)
> java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> com.acme.Foo$Factory.bar(Foo.java:93)
> As you can see, when bar method is called, VM tries to load
> com.acme.Foo.class and the call reaches
> org.apache.felix.framework.ModuleImpl.getEnclosingClass. getEnclosingClass
> actually causes the enclosing class, com.acme.Foo, to be defined. So, VM
> actually records this new class in loaded classes cache of the appropriate
> loader, but Felix does not consult the loaded classes cache again before
> trying to define the class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
