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 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.
My question is could this be disabled? Could there be some sort of
flag we could set to disable this "helpful" code? Since we are using
Felix in a web container, we have no idea what classes will be on the
call stack and would hate to have a plugin load fine in one container
but not in another. Furthermore, this could be considered to be a
security risk, as it allows a plugin to inadvertently gain access to
classes from the parent classloader, which could contain static state
it shouldn't have access to.
I'm happy to submit a patch if the solution of being able to turn it
off is agreed upon.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
