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)
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 ;
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.
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
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();
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.