2008/9/8 Don Brown <[EMAIL PROTECTED]> > https://issues.apache.org/jira/browse/FELIX-712 > > From what I can tell, there is a whole one test class for the > framework. Surely, I'm missing something? >
Richard and others also run the framework against the official OSGi TCK but unfortunately (IIRC) this cannot be part of the Felix build for licensing reasons - however, the results are available here: http://felix.apache.org/site/felix-osgi-tck-results.html we'd welcome contributions of more tests, especially when reporting bugs HTH Don > > On Tue, Sep 2, 2008 at 8:33 PM, Karl Pauls <[EMAIL PROTECTED]> wrote: > > Hi Don, > > > > this is interesting and we need to investigate it further. Could you > please > > create a jira issue for this and if possible attach a test that shows the > > problem? > > > > In case there is no real fix for the issue we will make it possible to > > disable parent delegation but I'd like to look at it first to see whether > we > > can fix it. > > > > regards, > > > > Karl > > > > Am 02.09.2008 um 08:53 schrieb "Don Brown" <[EMAIL PROTECTED]>: > > > >> 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] > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Stuart
