Error deserializing object

Bill

unread,

Oct 8, 2003, 10:06:09 PM10/8/03

to

I'm using WL 8.1. I got the following exceptions when I basically did this:

Message msg = queueReceiver.receive();
Object obj = ((ObjectMessage)msg).getObject(); //exception here

The ejb component is deployed as a single jar and the "missing" class, InternalMessage,
is in it. Checked full package etc. In fact, the message was sent internally and
no body complained when it was apparently made up fine.

Any idea what the cause might be?

TIA,
Bill

weblogic.jms.common.JMSException: Error deserializing object
.....
Caused by: java.lang.ClassNotFoundException: com.myco.app.server.msg.InternalMessage
at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:219)
at weblogic.jms.common.ObjectMessageImpl$ObjectInputStream2.resolveClass(ObjectMessageImpl.java:305)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
at weblogic.jms.common.ObjectMessageImpl.getObject(ObjectMessageImpl.java:130)
... 4 more

jasmeet

unread,

Oct 9, 2003, 12:12:18 PM10/9/03

to

If you could check that the class in question contains a no-argument constructor.
Its required for any kind of deserialisation

thanks
jaz

"Bill" <bi...@nospam.com> wrote:
>
>I'm using WL 8.1. I got the following exceptions when I basically did
>this:
>
>Message msg = queueReceiver.receive();
>Object obj = ((ObjectMessage)msg).getObject(); //exception here
>
>The ejb component is deployed as a single jar and the "missing" class,
>InternalMessage,
>is in it. Checked full package etc. In fact, the message was sent internally
>and
>no body complained when it was apparently made up fine.
>
>Any idea what the cause might be?
>
>TIA,
>Bill
>
>weblogic.jms.common.JMSException: Error deserializing object

>......

Bill

unread,

Oct 9, 2003, 1:19:27 PM10/9/03

to

Yes, it does. In fact, this used to be working and there is no code changes directly
on it. What we can trace back to is that we recently have been trying out different
clustering settings. Any thoughts on what in JMS Server/Queue configuration might
be able to cause this? Thanks a lot for responding. /Bill

Tom Barnes

unread,

Oct 9, 2003, 1:35:52 PM10/9/03

to Bill

I'm not sure that JMS configuration could have
an affect on this. The full stack trace might
reveal more about what is happening, could you
post it?

Bill

unread,

Oct 9, 2003, 3:21:33 PM10/9/03

to

You are right - let's take a more systematic look. The config could just be "noice".
So here is the trace. I don't know why the "...4 more" line. I also attached the
section in config.xml and the def of the complaining method.

(BTW - Tom, if you recall you were helping me in considering intra-cluster messaging.
I decided Distributed Topics would cover most of the needs. This problem started
to happen when we started to try out different configs. But this now happens whether
it's in the clustered env or not.)

10/09 15:03:51 ERROR [Thread-56] weblogic.jms.common.JMSException: Error deserializing
object
at weblogic.jms.common.ObjectMessageImpl.getObject(ObjectMessageImpl.java:144)
at myco.myapp.server.communication.internal.InternalPFSListener.convertMessage(InternalPFSListener.java:176)
at myco.myapp.server.communication.internal.InternalPFSListener.doBatch(InternalPFSListener.java:85)
at myco.myapp.server.communication.internal.InternalPFSListener.run(InternalPFSListener.java:73)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.lang.ClassNotFoundException: myco.myapp.server.bdt.InternalMessage

at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:219)
at weblogic.jms.common.ObjectMessageImpl$ObjectInputStream2.resolveClass(ObjectMessageImpl.java:305)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
at weblogic.jms.common.ObjectMessageImpl.getObject(ObjectMessageImpl.java:130)
... 4 more

//InternalPFSListener::convertMessage
private InternalMessage convertMessage(Message msg) throws Exception
{
//some debugging stuff...
return (InternalMessage)((ObjectMessage)msg).getObject();
}

//Definition of the Queue in config.xml
<JMSServer Name="myJMSServer" Store="myFileStore" Targets="myServer">
//other destinations
<JMSQueue
JNDIName="myco.myapp.server.internal.jms.PFSQueue"
JNDINameReplicated="false" Name="PFSQueue" StoreEnabled="default"/>
</JMSServer>

Bill

unread,

Oct 9, 2003, 5:01:41 PM10/9/03

to

I just noticed an earlier post regarding CR101198 in 8.1 Beta. The issue looked
so much like what we are having. But everywhere I looked, I didn't see "beta"
in the installation. What's the definitive way to find out the release version?

Tom Barnes

unread,

Oct 9, 2003, 6:10:13 PM10/9/03

to Bill

Hi Bill,

Is the app running on its own threads on the server? Seems
like it:

myco.myapp.server.communication.internal.InternalPFSListener.run(InternalPFSListener.java:73)
at java.lang.Thread.run(Thread.java:534)

This isn't supported. But, hey, everybody does it.

You will need to tell the thread
about the correct class-loader to use. I'm not sure
how, perhaps by caching it
from a server thread that has invoked one
of your EJBs, and then setting it on
your own thread. (This stretches the limit
of my class-loader knowledge, so I'll rope
a guru in if this advice doesn't suffice.)

Tom

Bill wrote:

> I just noticed an earlier post regarding CR101198 in 8.1 Beta. The issue looked
> so much like what we are having. But everywhere I looked, I didn't see "beta"
> in the installation. What's the definitive way to find out the release version?

java weblogic.version (I think)
or look at the beginning lines of your log file

Tom Barnes

unread,

Oct 9, 2003, 6:33:31 PM10/9/03

to ple...@replyinnewsgroup.com, Bill

Thread.currentThread().getContextClassLoader()
Thread.currentThread().setContextClassLoader()

Note that by calling "getObject()" in another
thread you are technically multi-threading the session.
It should be fine with WL JMS, as long as you
don't attempt to use the message again in the original
thread after passing it off.

Bill

unread,

Oct 9, 2003, 11:23:49 PM10/9/03

to

OK. This gets a bit more complicated and my hands got caught in the cookie jar
on the threading... Yes, but...

The child thread should use the parent's so it really shouldn't be a problem.
And since the session is established in the new thread after it starts, I'd think
we didn't multi-thread the session. Just to test with these issues in mind but
from a different angle, I did a load class from a SLSB (AdminSvcEJB):

try
{
ClassLoader cl = Thread.currentThread().getContextClassLoader();
cl.loadClass("InternalMessage");
}catch (Throwable t)
{
t.printStackTrace();
}

It still doesn't find it and gets the following, therefore the problem seems to
be more general.

10/09 21:58:51 DEBUG [ExecuteThread: '49' for queue: 'default'] [AdminSvcEJB::initializeServer]
classloader: weblogic.utils.classloaders.GenericClassLoader@7d811a finder: weblogic.utils.classloaders.MultiClassFinder@1a6fb3e
annotation: myejb@
10/09 21:58:51 ERROR [ExecuteThread: '49' for queue: 'default'] java.lang.ClassNotFoundException:
InternalMessage
at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:186)
at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at myco.myapp.server.service.AdminSvcEJB.initializeServer(AdminSvcEJB.java:930)
at myco.myapp.server.service.AdminSvc_760dph_EOImpl.initializeServer(AdminSvc_760dph_EOImpl.java:424)
at myco.myapp.server.service.AdminAdapterEJB.service(AdminAdapterEJB.java:166)
at myco.myapp.server.service.AdminAdapterEJB.service(AdminAdapterEJB.java:43)
at myco.myapp.server.service.AdminAdapter_45f3sz_EOImpl.service(AdminAdapter_45f3sz_EOImpl.java:97)
at myco.myapp.server.service.AdminAdapter_45f3sz_EOImpl_WLSkel.invoke(Unknown
Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:407)
at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:108)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:356)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:353)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:123)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:351)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:178)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:151)

Bill

unread,

Oct 9, 2003, 11:59:02 PM10/9/03

to

I apologize - that was a bad test. I should have put in the full class name and
the SLSB does find it. And I further tested by passing in the ClassLoader, it
all works. So, you are correct Tom. Thanks!

What's still puzzling, however, is that this class has been there and working
for at least months. We started trying out different config settings in the past
few days.

Great help. Thanks again!

chok...@gmail.com

unread,

Dec 11, 2013, 1:56:22 PM12/11/13

to

chok...@gmail.com

unread,

Dec 11, 2013, 2:19:37 PM12/11/13

to

I am getting the same error message fro my Clustered JMS message

public void onMessage(Message message){
Object obj=((ObjectMessage)message).getObject();
serviceRequestDTO=(ServiceRequestDTO)obj;
}

Error Stack trace

weblogic.jms.common.JMSException: [JMSClientExceptions:055115]Error deserializing an object
at weblogic.jms.common.ObjectMessageImpl.getObject(ObjectMessageImpl.java:190)
at hermes.renderers.DefaultMessageRenderer.handleObjectMessage(DefaultMessageRenderer.java:283)
at hermes.renderers.DefaultMessageRenderer.render(DefaultMessageRenderer.java:408)
at hermes.browser.components.MessagePayloadPanel.setMessage(MessagePayloadPanel.java:98)
at hermes.browser.actions.BrowserAction.updatePayloadPanel(BrowserAction.java:771)
at hermes.browser.actions.BrowserAction.valueChanged(BrowserAction.java:755)......

Caused by: java.lang.ClassNotFoundException: xx.yy.zz.dto.ServiceRequestDTO
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at hermes.impl.LoaderSupport$DebugClassLoader.findClass(LoaderSupport.java:130)

I have tried to load missing class using
1)Class.forName("xx.yy.zz.dto.ServiceRequestDTO");
2) In static initialiser
static{
SRListener.class.getClassLoader().loadClass("xx.yy.zz.dto.ServiceRequestDTO");

}
3) By loading ServiceRequestDTO.class in jar

Still i got the same error.

Now I will try as suggested

ClassLoader cl = Thread.currentThread().getContextClassLoader();
cl.loadClass("xx.yy.zz.dto.ServiceRequestDTO");

This happens only in our stagging environmenr all other env dev,test and prod runs fine.
I will let you know the progress.

Thanks,
Nilesh