felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Pauls (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-712) Ability to disable automatic parent classloader delegation
Date Mon, 08 Sep 2008 10:34:44 GMT

    [ https://issues.apache.org/jira/browse/FELIX-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629120#action_12629120

Karl Pauls commented on FELIX-712:

I still would like to see an example of this problem to make sure we fixed it :-).

Regardless, the hack should not just bootdelegate. Rather, the idea is to find the first class
on the call stack that is not from the class loader that loaded the Felix classes or is not
a class loader or class itself, because we want to ignore calls to ClassLoader.loadClass()
and Class.forName() since we are trying to find out who instigated the class load. 

In case the class determined in this fashion is from the outside _then_ we try to bootdelegate.
In other words, I think we just missed the case of somebody using Bundle.loadClass. Due to
the fact that Bundle is loaded using the framework classloader and the implementation uses
only classes from the same classloader we do bootdelegate and I agree that we shouldn't in
this case. 

IMO, we should try to special case for this scenario and fix the magic instead of moving the
responsibility to the user. 

> Ability to disable automatic parent classloader delegation
> ----------------------------------------------------------
>                 Key: FELIX-712
>                 URL: https://issues.apache.org/jira/browse/FELIX-712
>             Project: Felix
>          Issue Type: Improvement
>          Components: Framework
>    Affects Versions: felix-1.2.0
>            Reporter: Don Brown
> In debugging a strange issue why a certain test was passing in IDEA, but failing in Maven,
we discovered that under certain conditions, Felix will delegate to the parent classloader
if it detects another class in the stack who's classloader differs from the classloader of
Felix. Specifically, in org.apache.felix.framework.searchpolicy.R4SearchPolicyCore starting
in line 541, there is the problematic code block that has this comment:
>        // At this point, the class/resource could not be found by the bundle's
>        // static or dynamic imports, nor its own content. Before we throw
>        // an exception, we will try to determine if the instigator of the
>        // class/resource load was a class from a bundle or not. This is necessary
>        // because the specification mandates that classes on the class path
>        // should be hidden (except for java.*), but it does allow for these
>        // classes/resources to be exposed by the system bundle as an export.
>        // However, in some situations classes on the class path make the faulty
>        // assumption that they can access everything on the class path from
>        // every other class loader that they come in contact with. This is
>        // not true if the class loader in question is from a bundle. Thus,
>        // this code tries to detect that situation. If the class
>        // instigating the load request was NOT from a bundle, then we will
>        // make the assumption that the caller actually wanted to use the
>        // parent class loader and we will delegate to it. If the class was
>        // from a bundle, then we will enforce strict class loading rules
>        // for the bundle and throw an exception.
> What that means is if if you call Bundle.loadClass() from a non-bundle class and you
happen to have a class in your stack, which was loaded from a different classloader than Felix,
Felix will try to fix your problem by allowing parent classloader delegation. This was the
cause of the breakage for us because Maven's Surefire plugin uses its own classloader to load
several of its classes and Felix found those in the call stack and decided to enable parent
delegation. In IDEA, all the classes were loaded by the same classloader, so our tests passed.
> Specifically, we have code that sits outside Felix and tries to load classes from installed
bundles.  Felix sees that the call, by examining the stack, is by code outside a bundle, so
it enters this routine that may or may not, depending on the execution environment, delegate
the class loading to Felix's class loader.  
> This ticket asks for a configuration setting to be able to disable this bit of code.

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

View raw message