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

[Adrian Brock]

On Mon, 2010-02-15 at 13:17 +0100, Carlo de Wolf wrote:
> No, I didn't mean findLoadedClass, I meant findBootstrapClass0.
> 

That's not a part of the java.lang.ClassLoader api.
It's a Sun/Oracle implementation detail, that might not be there
in other JREs.

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

But that means entering a synchronized block and hence contention. 
Which we don't want to do unless we have to. 

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

-- 
xxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Redhat
xxxxxxxxxxxxxxxxxxxxx