You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall (JIRA)" <ji...@apache.org> on 2010/10/20 19:24:23 UTC
[jira] Created: (FELIX-2670) [Framework] Implicit boot delegation
doesn't delegate for external code in all cases
[Framework] Implicit boot delegation doesn't delegate for external code in all cases
------------------------------------------------------------------------------------
Key: FELIX-2670
URL: https://issues.apache.org/jira/browse/FELIX-2670
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-3.0.5
Reporter: Richard S. Hall
Priority: Minor
Fix For: framework-3.2.0
When determining if a class is not from a bundle in ModuleImpl.isClassNotLoadedFromBundle() (terrible method name, by the way), it attempts to ignore all framework classes by checking if the target class' class loader is the same as the framework's class loader. This check it too broad since the framework's class loader is typically the app class loader, which means that any other code on the class path will not trigger implicit boot delegation.
You could argue that implicit boot delegation was intended for JRE code and this is ok. However, just by changing the framework launcher to use a different class loader for the framework, you would get implicit boot delegation for code on the class path, so it seems odd that we trigger it under one situation but not another.
Perhaps the simple solution is to not perform a class loader check, but to compare the package namespace (i.e., use org.apache.felix.framework to determine framework classes).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2670) [Framework] Implicit boot delegation
doesn't delegate for external code in all cases
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-2670:
-----------------------------------
Fix Version/s: (was: framework-3.2.0)
framework-3.0.6
> [Framework] Implicit boot delegation doesn't delegate for external code in all cases
> ------------------------------------------------------------------------------------
>
> Key: FELIX-2670
> URL: https://issues.apache.org/jira/browse/FELIX-2670
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-3.0.5
> Reporter: Richard S. Hall
> Assignee: Richard S. Hall
> Priority: Minor
> Fix For: framework-3.0.6
>
> Attachments: FELIX-2670.txt
>
>
> When determining if a class is not from a bundle in ModuleImpl.isClassNotLoadedFromBundle() (terrible method name, by the way), it attempts to ignore all framework classes by checking if the target class' class loader is the same as the framework's class loader. This check is too broad since the framework's class loader is typically the app class loader, which means that any other code on the class path will not trigger implicit boot delegation.
> You could argue that implicit boot delegation was intended for JRE code and this is ok. However, just by changing the framework launcher to use a different class loader for the framework, you would get implicit boot delegation for code on the class path, so it seems odd that we trigger it under one situation but not another.
> Perhaps the simple solution is to not perform a class loader check, but to compare the package namespace (i.e., use org.apache.felix.framework to determine framework classes).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2670) [Framework] Implicit boot delegation
doesn't delegate for external code in all cases
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923680#action_12923680 ]
Richard S. Hall commented on FELIX-2670:
----------------------------------------
After some investigation and test case creation, I think the test for implicit boot delegation wasn't completely correct. We were trying to walk the stack to determine the ultimate class that triggered the entire class load request. In reality, I think we only want to find the first external class that called into the framework's class loading infrastructure.
If the immediate trigger class was loaded by a bundle, then OSGi rules apply and there is no implicit boot delegation.
If the immediate trigger class was loaded by an external class loader, then OSGi rules apply if Bundle.loadClass() is being called, but implicit boot delegation should occur if it is delegating to a module class loader.
I am attaching a patch that implements this approach, it simplifies the implicit boot delegation logic quite a bit. Also, it passes all of the tests I've created, although I still need to create a test for proxies. I will shortly apply this to trunk and then we should also try some real-world tests. If everything looks ok, then we will go back to addressing exceptional scenarios as they arise.
I am particularly interested if Guillaume could test his scenario from FELIX-962 to make sure it still works with this patch, since this is where I think we started to make things too complicated.
> [Framework] Implicit boot delegation doesn't delegate for external code in all cases
> ------------------------------------------------------------------------------------
>
> Key: FELIX-2670
> URL: https://issues.apache.org/jira/browse/FELIX-2670
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-3.0.5
> Reporter: Richard S. Hall
> Priority: Minor
> Fix For: framework-3.2.0
>
> Attachments: FELIX-2670.txt
>
>
> When determining if a class is not from a bundle in ModuleImpl.isClassNotLoadedFromBundle() (terrible method name, by the way), it attempts to ignore all framework classes by checking if the target class' class loader is the same as the framework's class loader. This check is too broad since the framework's class loader is typically the app class loader, which means that any other code on the class path will not trigger implicit boot delegation.
> You could argue that implicit boot delegation was intended for JRE code and this is ok. However, just by changing the framework launcher to use a different class loader for the framework, you would get implicit boot delegation for code on the class path, so it seems odd that we trigger it under one situation but not another.
> Perhaps the simple solution is to not perform a class loader check, but to compare the package namespace (i.e., use org.apache.felix.framework to determine framework classes).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-2670) [Framework] Implicit boot delegation
doesn't delegate for external code in all cases
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall closed FELIX-2670.
----------------------------------
Resolution: Fixed
Assignee: Richard S. Hall
I've applied a patch for this and have created several test cases for it that all pass. I also tested it against the scenario in FELIX-2653. Everything looks good, but it is possible that I'm missing something. We'll just address any regressions as they are discovered.
> [Framework] Implicit boot delegation doesn't delegate for external code in all cases
> ------------------------------------------------------------------------------------
>
> Key: FELIX-2670
> URL: https://issues.apache.org/jira/browse/FELIX-2670
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-3.0.5
> Reporter: Richard S. Hall
> Assignee: Richard S. Hall
> Priority: Minor
> Fix For: framework-3.2.0
>
> Attachments: FELIX-2670.txt
>
>
> When determining if a class is not from a bundle in ModuleImpl.isClassNotLoadedFromBundle() (terrible method name, by the way), it attempts to ignore all framework classes by checking if the target class' class loader is the same as the framework's class loader. This check is too broad since the framework's class loader is typically the app class loader, which means that any other code on the class path will not trigger implicit boot delegation.
> You could argue that implicit boot delegation was intended for JRE code and this is ok. However, just by changing the framework launcher to use a different class loader for the framework, you would get implicit boot delegation for code on the class path, so it seems odd that we trigger it under one situation but not another.
> Perhaps the simple solution is to not perform a class loader check, but to compare the package namespace (i.e., use org.apache.felix.framework to determine framework classes).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2670) [Framework] Implicit boot delegation
doesn't delegate for external code in all cases
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-2670:
-----------------------------------
Description:
When determining if a class is not from a bundle in ModuleImpl.isClassNotLoadedFromBundle() (terrible method name, by the way), it attempts to ignore all framework classes by checking if the target class' class loader is the same as the framework's class loader. This check is too broad since the framework's class loader is typically the app class loader, which means that any other code on the class path will not trigger implicit boot delegation.
You could argue that implicit boot delegation was intended for JRE code and this is ok. However, just by changing the framework launcher to use a different class loader for the framework, you would get implicit boot delegation for code on the class path, so it seems odd that we trigger it under one situation but not another.
Perhaps the simple solution is to not perform a class loader check, but to compare the package namespace (i.e., use org.apache.felix.framework to determine framework classes).
was:
When determining if a class is not from a bundle in ModuleImpl.isClassNotLoadedFromBundle() (terrible method name, by the way), it attempts to ignore all framework classes by checking if the target class' class loader is the same as the framework's class loader. This check it too broad since the framework's class loader is typically the app class loader, which means that any other code on the class path will not trigger implicit boot delegation.
You could argue that implicit boot delegation was intended for JRE code and this is ok. However, just by changing the framework launcher to use a different class loader for the framework, you would get implicit boot delegation for code on the class path, so it seems odd that we trigger it under one situation but not another.
Perhaps the simple solution is to not perform a class loader check, but to compare the package namespace (i.e., use org.apache.felix.framework to determine framework classes).
> [Framework] Implicit boot delegation doesn't delegate for external code in all cases
> ------------------------------------------------------------------------------------
>
> Key: FELIX-2670
> URL: https://issues.apache.org/jira/browse/FELIX-2670
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-3.0.5
> Reporter: Richard S. Hall
> Priority: Minor
> Fix For: framework-3.2.0
>
>
> When determining if a class is not from a bundle in ModuleImpl.isClassNotLoadedFromBundle() (terrible method name, by the way), it attempts to ignore all framework classes by checking if the target class' class loader is the same as the framework's class loader. This check is too broad since the framework's class loader is typically the app class loader, which means that any other code on the class path will not trigger implicit boot delegation.
> You could argue that implicit boot delegation was intended for JRE code and this is ok. However, just by changing the framework launcher to use a different class loader for the framework, you would get implicit boot delegation for code on the class path, so it seems odd that we trigger it under one situation but not another.
> Perhaps the simple solution is to not perform a class loader check, but to compare the package namespace (i.e., use org.apache.felix.framework to determine framework classes).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2670) [Framework] Implicit boot delegation
doesn't delegate for external code in all cases
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-2670:
-----------------------------------
Attachment: FELIX-2670.txt
> [Framework] Implicit boot delegation doesn't delegate for external code in all cases
> ------------------------------------------------------------------------------------
>
> Key: FELIX-2670
> URL: https://issues.apache.org/jira/browse/FELIX-2670
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-3.0.5
> Reporter: Richard S. Hall
> Priority: Minor
> Fix For: framework-3.2.0
>
> Attachments: FELIX-2670.txt
>
>
> When determining if a class is not from a bundle in ModuleImpl.isClassNotLoadedFromBundle() (terrible method name, by the way), it attempts to ignore all framework classes by checking if the target class' class loader is the same as the framework's class loader. This check is too broad since the framework's class loader is typically the app class loader, which means that any other code on the class path will not trigger implicit boot delegation.
> You could argue that implicit boot delegation was intended for JRE code and this is ok. However, just by changing the framework launcher to use a different class loader for the framework, you would get implicit boot delegation for code on the class path, so it seems odd that we trigger it under one situation but not another.
> Perhaps the simple solution is to not perform a class loader check, but to compare the package namespace (i.e., use org.apache.felix.framework to determine framework classes).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-2670) [Framework] Implicit boot
delegation doesn't delegate for external code in all cases
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923680#action_12923680 ]
Richard S. Hall edited comment on FELIX-2670 at 10/21/10 7:15 PM:
------------------------------------------------------------------
After some investigation and test case creation, I think the trigger for implicit boot delegation isn't completely correct. We are walking the stack to determine the ultimate originating class that triggered the entire class load request. In reality, I think we only want to find the first external class that called into the framework's class loading infrastructure.
If the immediate trigger class was loaded by a bundle, then OSGi rules apply and there is no implicit boot delegation.
If the immediate trigger class was loaded by an external class loader, then OSGi rules apply if Bundle.loadClass() is being called, but implicit boot delegation should occur if it is delegating to a module class loader.
I am attaching a patch that implements this approach, it simplifies the implicit boot delegation logic quite a bit. Also, it passes all of the tests I've created, although I still need to create a test for proxies. I will shortly apply this to trunk and then we should also try some real-world tests. If everything looks ok, then we will go back to addressing exceptional scenarios as they arise.
I am particularly interested if Guillaume could test his scenario from FELIX-962 to make sure it still works with this patch, since this is where I think we started to make things too complicated.
was (Author: rickhall):
After some investigation and test case creation, I think the test for implicit boot delegation wasn't completely correct. We were trying to walk the stack to determine the ultimate class that triggered the entire class load request. In reality, I think we only want to find the first external class that called into the framework's class loading infrastructure.
If the immediate trigger class was loaded by a bundle, then OSGi rules apply and there is no implicit boot delegation.
If the immediate trigger class was loaded by an external class loader, then OSGi rules apply if Bundle.loadClass() is being called, but implicit boot delegation should occur if it is delegating to a module class loader.
I am attaching a patch that implements this approach, it simplifies the implicit boot delegation logic quite a bit. Also, it passes all of the tests I've created, although I still need to create a test for proxies. I will shortly apply this to trunk and then we should also try some real-world tests. If everything looks ok, then we will go back to addressing exceptional scenarios as they arise.
I am particularly interested if Guillaume could test his scenario from FELIX-962 to make sure it still works with this patch, since this is where I think we started to make things too complicated.
> [Framework] Implicit boot delegation doesn't delegate for external code in all cases
> ------------------------------------------------------------------------------------
>
> Key: FELIX-2670
> URL: https://issues.apache.org/jira/browse/FELIX-2670
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-3.0.5
> Reporter: Richard S. Hall
> Priority: Minor
> Fix For: framework-3.2.0
>
> Attachments: FELIX-2670.txt
>
>
> When determining if a class is not from a bundle in ModuleImpl.isClassNotLoadedFromBundle() (terrible method name, by the way), it attempts to ignore all framework classes by checking if the target class' class loader is the same as the framework's class loader. This check is too broad since the framework's class loader is typically the app class loader, which means that any other code on the class path will not trigger implicit boot delegation.
> You could argue that implicit boot delegation was intended for JRE code and this is ok. However, just by changing the framework launcher to use a different class loader for the framework, you would get implicit boot delegation for code on the class path, so it seems odd that we trigger it under one situation but not another.
> Perhaps the simple solution is to not perform a class loader check, but to compare the package namespace (i.e., use org.apache.felix.framework to determine framework classes).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.