openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick (JIRA)" <j...@apache.org>
Subject [jira] Closed: (OPENJPA-311) Problem loading classes with OSGi classloaders
Date Fri, 10 Aug 2007 17:35:43 GMT

     [ 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.


Mime
View raw message