JMS ClassCastException problem in Jboss

[kchillar]

Hi I am using jboss 3.2.1.

I am using oracle 9.1 as JMS provider. I am able to send messages to the queue and deque them in normal operation.

However if I redeploy my classes after compilation and send fresh messages ( which will be new classes )
and deque ( which should be again of the same version as I sent ) I get ClassCastException.

I tried setting up
private static longserialVersionUID = 1234567812345678123L ;

in my message class to avoid this version problem
and it doesnot seem to help. Any suggestion will be greatly appreciated.

note: If I don't recompile jboss is able to deque messages without problem even if I shut it down and bring it up again. Only If I change ear it will give me problem.

Thank you
kchillar

[stephanenicoll]

Weird. So if you set this longVUID and clean up the queue it does not work?

Putting Java Objects inside a queue is hazardous, especially if you have to change the format in some way (cause, you'll have problems to rollout the new version if you have older messages in the queue).

What is the structure of your object (if your object contains another custome object you should also defined the longVUID for that one).

If you can, choose an XML representation, it's safer (JAXB can be used for that)

Regards,

Stephane

[kchillar]

Thanks for your suggestions, sorry I could not reply to your questions immediately. Some more details about my JMS Message

>What is the structure of your object (if your object contains another custome object you should also defined the longVUID for that one).

My Object has only two Strings and two File objects and one long field in it.

public MyMessageVO implements Serializable
{
private static final serialVersionUID = 1234123412341234123L ;

String f1;
String f2;
File f3;
File f4;
long f5;
}

How can I use XML representation, where can I find more details. But if you can point out any reason why its not working I would rather stick with this one instead on making changes now. We will go into production in another 15 days or so.


thank you

[stephanenicoll]

I don't want to imagine the structure of your application. Do you know that the J2EE specs prevent you to use the java.io package? (i.e. in no case should you access the filesystem in a J2EE components such as EJB, session beans, etc).

So you should not use File at all

Regards,

Stephane

[adrian.brock]

SerialVersionUID has nothing to do with ClassCastException

Try the following code after you receive the message:

ObjectMessage message = (ObjectMessage) receiver.receive();

Object object = message.getObject();
System,out.println("Oracle's version");
System.out.println(object.getClass());
System.out.println(object.getClass().getClassLoader());

System,out.println("My version");
System.out.println(MyMessageVO.class);
System.out.println(MyMessageVO.class.getClassLoader());

You will see they are different.

You have redeployed the classes, your application knows
about the new classes.

You haven't redeployed the Oracle client, it doesn't know
about the new classes. It is holding a reference to the old class.

This is an Oracle problem. Ask them what caching they do
and how you can workaround it.

My guess is this will turn out to be a Class.forName() problem,
i.e. the VM is caching the class.
If the Oracle client used the thread context classloader
it would probably work.

Regards,
Adrian