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

Out of curiosity, why doesn't isLoadedClass check the boot class loader? (apart from private API concerns)

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

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

Another one: 13:29:34,336 ERROR [STDERR] Exception in thread "WorkerThread#0[127.0.0.1:51198]" java.lang.NoClassDefFoundError: sun/reflect/SerializationConstructorAccessorImpl 13:29:34,338 ERROR [STDERR] at sun.misc.Unsafe.defineClass(Native Method) 13:29:34,338 ERROR [STDERR] at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45) 13:29:34,339 ERROR [STDERR] at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381) 13:29:34,339 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method) 13:29:34,339 ERROR [STDERR] at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:377) 13:29:34,340 ERROR [STDERR] at sun.reflect.MethodAccessorGenerator.generateSerializationConstructor(MethodAccessorGenerator.java:95) 13:29:34,340 ERROR [STDERR] at sun.reflect.ReflectionFactory.newConstructorForSerialization(ReflectionFactory.java:313) 13:29:34,341 ERROR [STDERR] at java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClass.java:1327)

13:29:34,349 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:12 Basically a class loader should always have the capabilities of the boot class loader.

(Apart from the real issue: class loader is shot before response leaves the server.)