[
https://issues.apache.org/jira/browse/FELIX-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall updated FELIX-712:
----------------------------------
Fix Version/s: felix-2.0.0
> 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
> Assignee: Karl Pauls
> Fix For: felix-2.0.0
>
> Attachments: delegate.patch
>
>
> 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.
