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,342 ERROR [STDERR] at
java.io.ObjectStreamClass.access$1500(ObjectStreamClass.java:52)
13:29:34,342 ERROR [STDERR] at
java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:437)
13:29:34,342 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native
Method)
13:29:34,343 ERROR [STDERR] at
java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:413)
13:29:34,343 ERROR [STDERR] at
java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
13:29:34,344 ERROR [STDERR] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1106)
13:29:34,344 ERROR [STDERR] at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
13:29:34,345 ERROR [STDERR] at
org.jboss.aop.joinpoint.InvocationResponse.writeExternal(InvocationResponse.java:100)
13:29:34,345 ERROR [STDERR] at
java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1421)
13:29:34,345 ERROR [STDERR] at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1390)
13:29:34,346 ERROR [STDERR] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
13:29:34,346 ERROR [STDERR] at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
13:29:34,347 ERROR [STDERR] at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
13:29:34,347 ERROR [STDERR] at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
13:29:34,348 ERROR [STDERR] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
13:29:34,348 ERROR [STDERR] at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
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.)
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.
>>>
>>
>
>