[Fwd: Re: jboss remoting 2.2.0.SPx update]
by Ron Sigal
-------- Original Message --------
Message-ID: <46421295.1080605(a)redhat.com>
Date: Wed, 09 May 2007 14:27:33 -0400
From: Ron Sigal <rsigal(a)redhat.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dimitris Andreadis <dandread(a)redhat.com>
CC: JBoss.org development list <jboss-development(a)lists.jboss.org>,
JBoss AS <jboss-as(a)redhat.com>
Subject: Re: jboss remoting 2.2.0.SPx update
References: <46420340.8030005(a)redhat.com>
In-Reply-To: <46420340.8030005(a)redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
1. I'm confused about the NotSerializableException -
org.jboss.invocation.Invocation in trunk/server/src/main really *isn't*
serializable. ???
2. All of the errors in the compatibility testsuite seem to be
"unsupported classversion 49.0". But I created the Remoting 2.2.0.SP4
jar with jdk 1.4.2_14-b05. ???
3. Also, for the socket transport, pooled connection checking has to be
compatible - "socket.check_connection" attribute.
-Ron
Dimitris Andreadis wrote:
> I updated Branch_4_2 to remoting 2.2.0.SP4 and added the
> -Djboss.remoting.pre_2_0_compatible=true flag on the server side, but
> that doesn't fix the compatibility testsuite.
>
> http://jira.jboss.com/jira/browse/JBAS-4407
>
> Also the latest jboss AS testsuite run is full of those exceptions:
>
> http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.2-testsuite-sun-1.5/2...
>
> Failed to communicate. Problem during marshalling/unmarshalling;
> nested exception is: java.io.NotSerializableException:
> org.jboss.invocation.Invocation
> java.rmi.MarshalException: Failed to communicate. Problem during
> marshalling/unmarshalling; nested exception is:
> java.io.NotSerializableException: org.jboss.invocation.Invocation
> at
> org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:122)
>
> at
> org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:641)
>
> at
> org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
>
> at org.jboss.remoting.Client.invoke(Client.java:1550)
> at org.jboss.remoting.Client.invoke(Client.java:530)
> at
> org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:175)
>
> at
> org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
>
> at
> org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
>
> at
> org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
>
> at
> org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
> at
> org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:184)
> at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
> at $Proxy1.findAll(Unknown Source)
> at
> org.jboss.test.bank.test.BankStressTestCase.setUp(BankStressTestCase.java:462)
>
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: java.io.NotSerializableException:
> org.jboss.invocation.Invocation
> at
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375)
>
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
>
> at
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
> at
> java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
> at
> org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:120)
>
> at
> org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:95)
>
> at
> org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120)
>
> at
> org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:964)
>
> at
> org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:554)
>
> ... 28 more
>
19 years, 3 months
jboss remoting 2.2.0.SPx update
by Dimitris Andreadis
I updated Branch_4_2 to remoting 2.2.0.SP4 and added the
-Djboss.remoting.pre_2_0_compatible=true flag on the server side, but that doesn't fix the
compatibility testsuite.
http://jira.jboss.com/jira/browse/JBAS-4407
Also the latest jboss AS testsuite run is full of those exceptions:
http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.2-testsuite-sun-1.5/2...
Failed to communicate. Problem during marshalling/unmarshalling; nested exception is:
java.io.NotSerializableException: org.jboss.invocation.Invocation
java.rmi.MarshalException: Failed to communicate. Problem during marshalling/unmarshalling;
nested exception is:
java.io.NotSerializableException: org.jboss.invocation.Invocation
at
org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:122)
at
org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:641)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
at org.jboss.remoting.Client.invoke(Client.java:1550)
at org.jboss.remoting.Client.invoke(Client.java:530)
at
org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:175)
at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:184)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
at $Proxy1.findAll(Unknown Source)
at org.jboss.test.bank.test.BankStressTestCase.setUp(BankStressTestCase.java:462)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
Caused by: java.io.NotSerializableException: org.jboss.invocation.Invocation
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at
org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:120)
at
org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:95)
at
org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120)
at
org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:964)
at
org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:554)
... 28 more
19 years, 3 months
Compatibility between common-core and broken up commons
by Tim Fox
Currently there doezn't seem to be any compatibility declared between
the old commons-core and broken up commons (commons-logging etc).
It seems JBAS 4.2 uses common-core, but JB 5 uses the broken up commons.
So an application (e.g. JBM) which uses common-core (and has all other
dependencies aligned with the AS) will work fine with AS 4.2, but won't
be guaranteed to work with JB5, since there's no guarantee AFAIK that
common-core and broken up commons are compatible.
At the moment AFAIK they are compatible - but isn't this a "hope for the
best" compatibility. I.e. what's stopping someone from making an
incompatible change to the broken up commons?
Shouldn't we be definining some kind of hard compatibility between the
jars? Especially with the new RHEL style, highly tested platform
releases where we need to be sure everything works nice with everything
else.
19 years, 3 months
