serialization exception with mustang

[elkner]

I wanna test (and actually really wanna use) 1.6 with my EJB3 standalone clients. Unfortunately it seems to be impossible dueto a serialization problem:

23:19:40,103 [Thread-4] ERROR (SocketClientInvoker.java:293) - Got marshalling exception, exiting
java.lang.ClassNotFoundException: [Ljava.lang.String;
 at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
 at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:50)
 at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:139)
 at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
 at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
 at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1624)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
 at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:122)
 at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
 at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128)
 at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66)
 at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279)
 at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
 at org.jboss.remoting.Client.invoke(Client.java:525)
 at org.jboss.remoting.Client.invoke(Client.java:488)
 at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
 at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
 at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
 at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
 at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
 at $Proxy0.hasRoles(Unknown Source)
 at foo.JbossLoginService.authenticate(JbossLoginService.java:69)
 at com.ehsbe.commons.gui.JxLoginDialog$LoginThread.run(JxLoginDialog.java:404)
23:19:40,114 [Thread-4] ERROR (SocketClientInvoker.java:297) - Error loading classes from remote call result.
...

The invoked EJB3 SLSB method is:
public String[] hasRoles(String[] roleNames) { .... }

Does this mean, that JBoss does not use Java serialization correctly and thus is incompatible with 1.6 ?

BTW: Just did a test using the normal java.io.{Output|Input}Stream and there is no problem at all wrt. writing and reading on Object, which contains String[]. Tested all combinations wrt. obj write/read and 1.5/1.6 ... hmmm

Any hints?

[clebert.suconic]

There is a bug with JBoss Serialization 1.0 about arrays.

You could or upgrade JBoss to 4.0.4.SP1, or upgrade jboss-serialization.jar in your lib to 1.0.1.GA.

What you mean to not compatible to 1.6?
on that context we are using JBossSerialization to serialize StatefulSessionBeans, which the specification doesn't require implementing java.io.Serializable.

[elkner]

There is a bug with JBoss Serialization 1.0 about arrays.

Hmmm, as far as I can see, JBoss Serialization is not used. I digged a little bit around, found the source for org.jboss.remoting.loading.ObjectInputStreamWithClassLoader (I think in the 1_4_1 branch) and replaced

protected Class resolveClass(java.io.ObjectStreamClass v)
 throws java.io.IOException, ClassNotFoundException
 {
 if(cl == null)
 {
 return super.resolveClass(v);
 }
 else
 {
 return cl.loadClass(v.getName());
 }
 }

with

protected Class resolveClass(java.io.ObjectStreamClass v)
 throws java.io.IOException, ClassNotFoundException
 {
 if(cl == null)
 {
 return super.resolveClass(v);
 }
 return Class.forName(v.getName(), false, cl);
 }

and finally updated the original jboss-remoting.jar with the compiled class. That fixes the problem.

You could or upgrade JBoss to 4.0.4.SP1, or upgrade jboss-serialization.jar in your lib to 1.0.1.GA.

Ohhh, missed the announcement. So, I'll try it with SP1.

What you mean to not compatible to 1.6?
on that context we are using JBossSerialization to serialize StatefulSessionBeans, which the specification doesn't require implementing java.io.Serializable.

Ehmmm, with 1.6 incompatible I just mean, the client runs with jdk1.5, but not with jdk1.6 beta2 aka b86 because of the shown exception. Not tried SFSB yet ...

BTW: Is there a way, to force either JBoss or Java "native" Serialization?

[clebert.suconic]

JBossSerialization is tested with JDK 1.6 on cruisecontrol.

The Bug I was talking about was identified on every JVM, was reproduced with a testcase, and is also tested with JDK 1.6.

Bugs happens ;-) (even with the JDK)

[elkner]

You could or upgrade JBoss to 4.0.4.SP1

Hmmm, can't find 4.0.4SP1 on sf.net (only the GA). Is there a hidden place, where one can download it?

[elkner]

The Bug I was talking about was identified on every JVM

At least it is consistent than ;-)

Bugs happens ;-) (even with the JDK)

Yepp ;-)

[clebert.suconic]

"elkner" wrote:

You could or upgrade JBoss to 4.0.4.SP1

Hmmm, can't find 4.0.4SP1 on sf.net (only the GA). Is there a hidden place, where one can download it?

It was planned to happen, but I didn't know the status (sorry)

I was traveling and don't know if was released or not. It should be out soon.

You could upgrade jboss-serialization.jar

http://labs.jboss.com/portal/serialization/downloads

Or on sourceforge also.

[elkner]

OK, just to give it a try (usually I wanna use/test officially realeased as) I downloaded and installed the 1.0.1. As I already guessed, it doesn't fix the problem, since JBoss Serialization is not used. Still need to use my patched version of jboss-remoting.jar ...

[clebert.suconic]

Oh man... really sorry... I was really dumb now.

This stack trace it's not a JBossSerialization's code indeed. You know... Sunday night... eh eh

I will wait (and ask) someone from Remoting to take a look on this thread.

[elkner]

OK, Thanx! Going to bed now as well, otherwise I'll probably loose the path as well ;-)

[tom.elrod]

Just to review, this error only happens when using jdk 1.6, but works with jdk 1.5, right? I can make the update to use the other forName() method signature as you mentioned, but only problem is that current code base is for 2.0.0 release, which is going to be impossible to test with the current code base.

Do you mind opening a jira issue against JBossRemoting project for this with link to this forum thread? If you have a test case specific to remoting (without using ejb3, but just remoting) that would be awesome.

[elkner]

Just to review, this error only happens when using jdk 1.6, but works with jdk 1.5, right?

Yepp.

I can make the update to use the other forName() method signature as you mentioned, but only problem is that current code base is for 2.0.0 release, which is going to be impossible to test with the current code base.

Not sure, whether I understood this correctly. Anyway, IMHO forName should be ok and perhaps even safer, since if available, it obeys the security managers hint ;-)

Do you mind opening a jira issue against JBossRemoting project for this with link to this forum thread?

Done. See http://jira.jboss.com/jira/browse/JBREM-508 - hope its enough info ;-)

If you have a test case specific to remoting (without using ejb3, but just remoting) that would be awesome.

Unfortunately I have not and haven't had the chance yet, to dive into the remoting test suite :(. But anyway, you are probably much, much faster, doing this right ;-)

[tom.elrod]

Have made the code change. I checked into remoting CVS HEAD (so will be part of 2.0.0 release).

Am checking into having remoting testsuite run under jdk 1.6 with cruisecontrol to try and catch any jdk 1.6 issues.