You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Michael Dick (JIRA)" <ji...@apache.org> on 2007/08/09 21:51:42 UTC
[jira] Created: (OPENJPA-311) Problem loading classes with OSGi
classloaders
Problem loading classes with OSGi classloaders
----------------------------------------------
Key: OPENJPA-311
URL: https://issues.apache.org/jira/browse/OPENJPA-311
Project: OpenJPA
Issue Type: Bug
Affects Versions: 0.9.7, 0.9.6, 0.9.0, 1.0.0
Reporter: Michael Dick
Assignee: Michael Dick
Fix For: 1.0.0
The root of the problem appears to be in the GeneratedClasses.getMostDerivedLoader method.
GetMostDerivedLoader takes two classes (class1 & class2) gets their respective classloaders (classloader1, & classloader2 respectively) and looks for a match. If the classloaders are not the same, and neither is null it calls getParent on classloader1 until classloader2 is found, or until there are no more parent loaders. If a match is found the mostDerivedLoader is considered to be classloader1, if no match is found we use classloader2.
The problem comes in when you have an OSGI classloader involved. The specific scenario I ran into has classloader1 calling getParent and encountering an OSGI gateway classloader, but not classloader2 (which is behind the OSGI gateway). Conceptually classloader2 is a parent of classloader1, but the OSGI gateway classloader hides it and we aren't able to find it.
I'm probably mangling the OSGI terminology a bit but I think this captures the essence of the problem.
It seems to me that the intent of the getMostDerivedLoader is to ensure that we use a classloader that has the "right" version of class2, preferring classloader1. If that's the case then would it be possible to just try to load class2 from classloader1 and compare the result to the original class? I believe this approach would work for OSGI classloaders, but I have a nagging feeling that I'm missing something.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-311) Problem loading classes with OSGi
classloaders
Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dick updated OPENJPA-311:
---------------------------------
Attachment: OPENJPA-311.diff.txt
> Problem loading classes with OSGi classloaders
> ----------------------------------------------
>
> Key: OPENJPA-311
> URL: https://issues.apache.org/jira/browse/OPENJPA-311
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 0.9.0, 0.9.6, 0.9.7, 1.0.0
> Reporter: Michael Dick
> Assignee: Michael Dick
> Fix For: 1.0.0
>
> Attachments: OPENJPA-311.diff.txt
>
>
> The root of the problem appears to be in the GeneratedClasses.getMostDerivedLoader method.
> GetMostDerivedLoader takes two classes (class1 & class2) gets their respective classloaders (classloader1, & classloader2 respectively) and looks for a match. If the classloaders are not the same, and neither is null it calls getParent on classloader1 until classloader2 is found, or until there are no more parent loaders. If a match is found the mostDerivedLoader is considered to be classloader1, if no match is found we use classloader2.
> The problem comes in when you have an OSGI classloader involved. The specific scenario I ran into has classloader1 calling getParent and encountering an OSGI gateway classloader, but not classloader2 (which is behind the OSGI gateway). Conceptually classloader2 is a parent of classloader1, but the OSGI gateway classloader hides it and we aren't able to find it.
> I'm probably mangling the OSGI terminology a bit but I think this captures the essence of the problem.
> It seems to me that the intent of the getMostDerivedLoader is to ensure that we use a classloader that has the "right" version of class2, preferring classloader1. If that's the case then would it be possible to just try to load class2 from classloader1 and compare the result to the original class? I believe this approach would work for OSGI classloaders, but I have a nagging feeling that I'm missing something.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (OPENJPA-311) Problem loading classes with OSGi
classloaders
Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dick closed OPENJPA-311.
--------------------------------
> Problem loading classes with OSGi classloaders
> ----------------------------------------------
>
> Key: OPENJPA-311
> URL: https://issues.apache.org/jira/browse/OPENJPA-311
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 0.9.0, 0.9.6, 0.9.7, 1.0.0
> Reporter: Michael Dick
> Assignee: Michael Dick
> Fix For: 1.0.0
>
> Attachments: OPENJPA-311.diff.txt
>
>
> The root of the problem appears to be in the GeneratedClasses.getMostDerivedLoader method.
> GetMostDerivedLoader takes two classes (class1 & class2) gets their respective classloaders (classloader1, & classloader2 respectively) and looks for a match. If the classloaders are not the same, and neither is null it calls getParent on classloader1 until classloader2 is found, or until there are no more parent loaders. If a match is found the mostDerivedLoader is considered to be classloader1, if no match is found we use classloader2.
> The problem comes in when you have an OSGI classloader involved. The specific scenario I ran into has classloader1 calling getParent and encountering an OSGI gateway classloader, but not classloader2 (which is behind the OSGI gateway). Conceptually classloader2 is a parent of classloader1, but the OSGI gateway classloader hides it and we aren't able to find it.
> I'm probably mangling the OSGI terminology a bit but I think this captures the essence of the problem.
> It seems to me that the intent of the getMostDerivedLoader is to ensure that we use a classloader that has the "right" version of class2, preferring classloader1. If that's the case then would it be possible to just try to load class2 from classloader1 and compare the result to the original class? I believe this approach would work for OSGI classloaders, but I have a nagging feeling that I'm missing something.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-311) Problem loading classes with OSGi
classloaders
Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dick resolved OPENJPA-311.
----------------------------------
Resolution: Fixed
> Problem loading classes with OSGi classloaders
> ----------------------------------------------
>
> Key: OPENJPA-311
> URL: https://issues.apache.org/jira/browse/OPENJPA-311
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 0.9.0, 0.9.6, 0.9.7, 1.0.0
> Reporter: Michael Dick
> Assignee: Michael Dick
> Fix For: 1.0.0
>
> Attachments: OPENJPA-311.diff.txt
>
>
> The root of the problem appears to be in the GeneratedClasses.getMostDerivedLoader method.
> GetMostDerivedLoader takes two classes (class1 & class2) gets their respective classloaders (classloader1, & classloader2 respectively) and looks for a match. If the classloaders are not the same, and neither is null it calls getParent on classloader1 until classloader2 is found, or until there are no more parent loaders. If a match is found the mostDerivedLoader is considered to be classloader1, if no match is found we use classloader2.
> The problem comes in when you have an OSGI classloader involved. The specific scenario I ran into has classloader1 calling getParent and encountering an OSGI gateway classloader, but not classloader2 (which is behind the OSGI gateway). Conceptually classloader2 is a parent of classloader1, but the OSGI gateway classloader hides it and we aren't able to find it.
> I'm probably mangling the OSGI terminology a bit but I think this captures the essence of the problem.
> It seems to me that the intent of the getMostDerivedLoader is to ensure that we use a classloader that has the "right" version of class2, preferring classloader1. If that's the case then would it be possible to just try to load class2 from classloader1 and compare the result to the original class? I believe this approach would work for OSGI classloaders, but I have a nagging feeling that I'm missing something.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.