[jira] Assigned: (FELIX-712) Ability to disable automatic parent classloader delegation
[ https://issues.apache.org/jira/browse/FELIX-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall reassigned FELIX-712: - Assignee: Richard S. Hall (was: Karl Pauls) > 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: Richard S. Hall > 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.
[jira] Assigned: (FELIX-712) Ability to disable automatic parent classloader delegation
[ https://issues.apache.org/jira/browse/FELIX-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls reassigned FELIX-712: Assignee: Karl Pauls > 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 > > 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.
