JDK-6367956 : GregorianCalendar deserialization error
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io:serialization
  • Affected Version: 1.4.2
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2005-12-30
  • Updated: 2011-02-16
  • Resolved: 2006-08-14
Related Reports
Duplicate :  
Relates :  
Description
Customer (BEA) reported the problem as follows:

Standalone java client is sending the ObjectMessage to a queue. Applet
is consumer which is running inside weblogic. Applet fails to receive
the message with 

Caused by: java.io.StreamCorruptedException

	at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1301)

	at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845)

	at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769)

	at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646
)

	at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)

	at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)

	at
weblogic.jms.common.ObjectMessageImpl.getObject(ObjectMessageImpl.java:1
31


This happens with ObjectMessage which has an GeegorianCalender
attribute. If we replace this attribute with java.util.Date then applet
is able to receive the message. 

Entire setup works even with GregorianCalender if applet is not
consumer(if consumer is an MDB or standalone java client).

I have uploaded the domain. Steps to see the problem:

1. Extract the zip into a dir
2. Install BEA weblogic 81 sp4
3. Modify setEnv.cmd and startWeblogic.cmd to point to BEA_HOME and
JAVA_HOME
4. Edit config.xml and delete all encrypted password

5. Start a WLS instance with that attached config.xml which contains all
the 
queue definitions.

6. add the workspace-applet-client.jar along with weblogic.jar to the 
document root of the .war file.  The client.jar contains the customers 
receiver code, along with sender code.  Deploy the .war to a server
running 
on port 7001, in the applet itself you can change the port if necessary
of 
the JNDI lookup for the receiver. default is t3://localhost:7001.

6. Start the receiver go to /MessengerApplet/slimtestJMS.jsp (this jsp
uses 
weblogic.jar as the archive)

7. Start the sender run java com.fnx.napa.applet.workspace.Sender with
the 
client.jar in the classpath.  This will send one message for which the 
receiver will try to receive, but fail with exception in the java
console for 
the webbrowser.

8. View Java Console and you should see this exception
9. Modify the ObjectIncoming.java to replace GregorianCalender, problem
will go away.

Cu tested it with 1.4.2_05 and 1.4.2_10 both on client side and server side. OS 
is Windows 2000 and same behavior could be seen on any OS.

The file location is at /net/cores.central/cores/64860102 

You will see the following 2 files listed there.

-rw-rw-rw-   1 rm111379 staff    39091630 Dec 29 13:42 612705.zip 
-rw-rw-rw-   1 rm111379 staff      14102 Dec 29 13:39 workspace-applet-client1.jar


--------------------------------------

Fui-Shien reproduced the problem in a lab machine and provided the following evaluation:

1.  Its a bug, most likely 4844924.  Which is too complex to fix in 1.4.2

2.  Weblogic server is running at s4u-v240b.singapore.sun.com,  
    (userid/passwd see comments section)
    Please note that the lab setup may not be around for long.

3.  cd /usr/local/bea/user_projects/domains/612705
./startWeblogic.sh

4.  I have written a simple jms client to receive message.  It doesnt fail like 
the applet.
cd /usr/local/bea/user_projects/domains/612705
java  -classpath /usr/local/bea/weblogic81/server/lib/wljmsclient.jar:. com.fnx.
napa.applet.workspace.App

5.  Their test case, after modification, point browser http://s4u-v240b.singapor
e.sun.com:7001/MessengerApplet/a.html

6.  To send messages,
cd /usr/local/bea/user_projects/domains/612705
java -classpath workspace-applet-client1.jar:/usr/local/bea/weblogic81/server/lib/weblogic.jar com.fnx.napa.applet.workspace.Sender

You should see that the client written in 4. didnt fail, and the applet fails.

7.  Now trying for 1.5.0_06 and 1.6.0-rc-b61

jdk1.6.0/bin/appletviewer -J-Djava.security.policy==/net/nemo.singapore/export/h
ome/fschoong/tasks/bea/java.policy http://s4u-v240b.singapore.sun.com:7001/Messe
ngerApplet/a.html

jdk1.5.0_06/bin/appletviewer -J-Djava.security.policy==/net/nemo.singapore/expor
t/home/fschoong/tasks/bea/java.policy http://s4u-v240b.singapore.sun.com:7001/Me
ssengerApplet/a.html

However, you can see that it will only work once...  Probably WL8.1 is not certi
fied to work with 1.5.0/1.6 yet.  I have no real workaround yet then.

All said, I wonder why customer is making an applet and sending weblogic.jar acr
oss the wire and connect to the backend via JMS.  Their config.xml shows that th
ey have intentions of making more queues.  Not sure if > 10 clients connectin
g via JMS over internet is a feasible architecture.

If this is deployed in the intranet, they can use either Java Web Start (which s
houldnt have this problem) or a plain application.

Here's the exception logged in java console:

Exception encountered ....

weblogic.jms.common.JMSException: Error deserializing object

	at weblogic.jms.common.ObjectMessageImpl.getObject(ObjectMessageImpl.java:143)

	at com.fnx.napa.applet.workspace.OurJMSUtil.toFNXMessage(OurJMSUtil.java:14)

	at com.fnx.napa.applet.workspace.Reciever$1.onMessage(Reciever.java:122)

	at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2678)

	at weblogic.jms.client.JMSSession.execute(JMSSession.java:2598)

	at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)

	at weblogic.kernel.Kernel.execute(Kernel.java:343)

	at weblogic.kernel.Kernel.execute(Kernel.java:367)

	at weblogic.kernel.Kernel.execute(Kernel.java:355)

	at weblogic.jms.client.JMSSession.pushMessage(JMSSession.java:2474)

	at weblogic.jms.client.JMSSession.invoke(JMSSession.java:3006)

	at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:643)

	at weblogic.jms.dispatcher.DispatcherImpl.dispatchAsyncInternal(DispatcherImpl.java:132)

	at weblogic.jms.dispatcher.DispatcherImpl.dispatchOneWay(DispatcherImpl.java:341)

	at weblogic.jms.dispatcher.DispatcherImpl_WLSkel.invoke(Unknown Source)

	at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:477)

	at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:420)

	at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)

	at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)

	at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:415)

	at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)

	at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)

	at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)

Caused by: java.io.StreamCorruptedException

	at java.io.ObjectInputStream.readObject0(Unknown Source)

	at java.io.ObjectInputStream.defaultReadFields(Unknown Source)

	at java.io.ObjectInputStream.readSerialData(Unknown Source)

	at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)

	at java.io.ObjectInputStream.readObject0(Unknown Source)

	at java.io.ObjectInputStream.readObject(Unknown Source)

	at weblogic.jms.common.ObjectMessageImpl.getObject(ObjectMessageImpl.java:131)

	... 22 more

Comments
EVALUATION From the description, I don't think this has anything to do with CORBA. So I am moving this bug to java/java/serialization.
13-08-2006