Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <2139369512.1240254108553.JavaMail.jira@brutus>
Date: Mon, 20 Apr 2009 12:01:48 -0700 (PDT)
From: "Vivek Pandey (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Created: (FELIX-1045) Felix 1.6.0 fails with
 ClassCircularityError
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Felix 1.6.0 fails with ClassCircularityError
--------------------------------------------

                 Key: FELIX-1045
                 URL: https://issues.apache.org/jira/browse/FELIX-1045
             Project: Felix
          Issue Type: Bug
            Reporter: Vivek Pandey


In Glassfish v3, JRuby runtime classes are loaded by a URLClassLoader form inside an OSGi bundle. This all worked fine till upgrade to Felix 1.6.0. With felix 1.6.0 it fails with ClassCircularityError. See [1] below. This issue seems to be related to FELIX-962. 

This is 
discussed on dev@glassfish at http://www.nabble.com/Re:-ClassCircularityError-reported-with-the-
latest-v3-trunk-td23118716.html. 

Here is the evaluation of this issue by Richard Hall, a patched version of felix.jar is tested and it works 
fine. 

----------
This code in Felix should only ever be executed when there is a CNFE that is going to be thrown. Do 
you know if you should correctly be getting a CNFE?

To be clear, the explicit issue we are talking about is this change in Felix:

    http://issues.apache.org/jira/browse/FELIX-962

We actually try to determine if a class is an inner class of a class loader when we are trying to guess 
whether or not we should delegate to the parent class loader. This is part of a hack which is a last ditch 
effort to avoid CNFE for bad JRE code that assumes it should be able to see everything on the class path 
from any class loader.

The change from FELIX-962 is actually implemented in two different ways, one for JDK < 1.5 and one 
for JDK >= 1.5. In the >= 1.5 version we use the method Class.getEnclosingClass(), which seems to 
cause the error for perhaps the reasons in the JDK bug you referenced. We implemented the two 
different approaches since we assumed performance would be better by just using getEnclosingClass() 
than trying to figure it out the enclosing class manually, which involves doing a class load.

We could potentially try always using the < 1.5 approach, which does not use that method. If I created 
a felix.jar that did that, could you test it to see if it resolved the issue? 
----------

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.