[jboss-dev] findLoaded bootstrap class WAS Re: Possible blocker with jboss-cl 2.2.0.Alpha1 [WAS]: Hudson Jobs Hanging

[Carlo de Wolf]

No, I didn't mean findLoadedClass, I meant findBootstrapClass0.

So:

    protected Class<?>  isLoadedClass(String name, boolean trace)
    {
       Class<?>  result = findLoadedClass(name);
       // new bit
       if (result == null) { result = findBootstrapClass0(name); if (result != null); return result; }

       if (result != null)
       {

It could do this better by just delegating to a new ClassLoader with 
null parent.

Carlo

On 02/15/2010 01:13 PM, Adrian Brock wrote:
> On Mon, 2010-02-15 at 12:48 +0100, Carlo de Wolf wrote:
>    
>> Out of curiosity, why doesn't isLoadedClass check the boot class loader?
>> (apart from private API concerns)
>>
>>      
> You mean something like:
>
>     protected Class<?>  isLoadedClass(String name, boolean trace)
>     {
>        // Short cut for java.* classes
>        if (ClassFilterUtils.NOTHING_BUT_JAVA.matchesClassName(name))
>        {
>           Class<?>  result = getSystemClassLoader().findLoadedClass(name);
>           if (result != null)
>              return result;
>        }
>
>        // Existing code
>        Class<?>  result = findLoadedClass(name);
>        if (result != null)
>        {
>
> // etc
>
> Like you say, findLoadedClass() has protected access so it would
> need to use reflection to make it accessible.
>
> We could only do that for java.* classes since all the other ones
> could be in isolated/filtered classloaders meaning it wouldn't want
> the version from the bootstrap classloader.
>
> It would also only be relevant the first time this classloader
> initiates a request to load the class. Once it has done it once,
> the existing findLoadedClass() check should remember it
> (assuming the class doesn't get garbage collected).
>
>    
>> Carlo
>>
>> On 02/09/2010 05:01 PM, Adrian Brock wrote:
>>      
>>> trunk is now using jboss-cl 2.2.0.Alpha2
>>>
>>> On Tue, 2010-02-09 at 09:30 -0600, Brian Stansberry wrote:
>>>
>>>        
>>>> LOL. Thanks; I thought this had been shifted to jboss-dev.
>>>>
>>>> On 02/09/2010 09:20 AM, Ales Justin wrote:
>>>>
>>>>          
>>>>> To put this on jboss-dev.
>>>>> (as Brian is probably reading emails in chronological order :-))
>>>>>
>>>>> The CL 2.2.0.Alpha2 was just tagged. ;-)
>>>>>
>>>>> On Feb 9, 2010, at 4:06 PM, Brian Stansberry wrote:
>>>>>
>>>>>
>>>>>            
>>>>>> On 02/09/2010 04:50 AM, Adrian Brock wrote:
>>>>>>
>>>>>>              
>>>>>>> On Mon, 2010-02-08 at 22:02 -0600, Brian Stansberry wrote:
>>>>>>>
>>>>>>>                
>>>>>> <snip/>
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> There is however a change in behaviour since jboss-4.2.x in that
>>>>>>> you could always load java.lang.* classes even when the classloader
>>>>>>> was shutdown.
>>>>>>>
>>>>>>> This was because of a shortcut in the old UCL classloader:
>>>>>>> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/branches/Branch_4_2/jmx/src/main/org/jboss/mx/loading/RepositoryClassLoader.java?r1=60321&r2=63960 to workaround this problem:
>>>>>>> https://jira.jboss.org/jira/browse/JBAS-4536
>>>>>>> which doesn't exist with the new classloader when correctly configured.
>>>>>>>
>>>>>>> I can restore the 4.2.x behaviour, but I don't think it
>>>>>>> is the real problem?
>>>>>>>
>>>>>>> In both examples on JBAS-7688, it would still fail if it tried to
>>>>>>> load a common/lib class at that point, e.g. javax.ejb.*
>>>>>>> or any other class not in the classloader that is shutdown.
>>>>>>>
>>>>>>>                
>>>>>> Good point. Still, https://jira.jboss.org/jira/browse/JBCL-145 seems useful, since a lot of responses only involve JDK classes.
>>>>>>
>>>>>> I don't see any reason to not use jboss-cl 2.2.x in M2; the clean shutdown behavior the ejbthree1116 is testing doesn't work, which isn't the fault of jboss-cl.
>>>>>>
>>>>>> It would be nice though to have a jboss-cl 2.2.0.Alpha2 w/ the JBCL-145 fix to reduce the probability of this kind of failure.
>>>>>>
>>>>>> Thanks, everyone, for digging into this.
>>>>>>
>>>>>>              
>>>>>
>>>>>            
>>>>
>>>>          
>>>
>>>        
>>      
>