openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: PCRegistry ClassLoader memory leak
Date Tue, 17 Jul 2007 14:16:43 GMT

On Jul 17, 2007, at 12:15 AM, Craig L Russell wrote:

>
> On Jul 16, 2007, at 7:48 PM, Kevan Miller wrote:
>
>>
>> On Jul 16, 2007, at 10:26 PM, Pinaki Poddar wrote:
>>
>>> Just to clarify:
>>> I meant it should be the loader that loaded Person.class where  
>>> Person is
>>> the persistence capable class, *not*
>>> org.apache.openjpa.enhance.PersistenceCapable.class.getClassLoader 
>>> ().
>>>
>>> But testing in multi-classloader environment is required to  
>>> validate any
>>> changes of this nature.
>>
>> Yes, that's how I interpreted your statement. My point is that if  
>> SSN is a field of Person, the ClassLoader of SSN is not  
>> necessarily the ClassLoader for Person. I'd be concerned that the  
>> Person ClassLoader can't load SSN. In that case, your technique  
>> wouldn't work...
>
> Just to clarify, if SSN is the type of a field of Person, the  
> ClassLoader of Person.class must be able to load SSN (either itself  
> or via a parent ClassLoader) or you will have a linkage error while  
> loading Person.

Craig,
You are correct. The declared type must be loadable. I was thinking  
of an SSNImpl type which need not be. However, that's not really  
relevant to the problem at hand...

Pinaki,
I'm afraid that I may have improperly narrowed your objectives by  
singling out fieldTypes. PCRegistry$Meta.pc and pcSuper could also  
keep Classes/ClassLoaders alive...

--kevan

Mime
View raw message