InvalidClassException in throwing EJBException from WebLogic 6.1 to WebLogic 7.0

Question

We are running two versions of WL and need to run the GUI part of App
on 7.0 and the business part on 6.1.
We get an exception on 6.1 but in handling the exception on 7.0 we get
the following error:
java.io.InvalidClassException: javax.ejb.EJBException; Local class not
compatibl
e: stream classdesc serialVersionUID=-9219910240172116449 local class
serialVers
ionUID=796770993296843510
Sure enough the EJBException class on the different servers have
different serial version numbers. Of course, the root cause is
something else but we need to be able to handle exceptions throw from
one to another.
Any ideas on the best way to handle this?

Answer 1

That's understandable. I believe EJBException is the only class you'll
need to change, but it's worth testing.
If you're uncomfortable adding the class to the front of the classpath,
you'll have to open a case with [email protected] to get an official patch.
-- Rob
Jim Cross wrote:
I believe that would probably solve the problem but I don't feel
particularly comfortable with replacing WebLogic classes.
How many other classes would we need to do this with?
FinderException?CreateException? What else?
Rob Woollen <[email protected]> wrote in message news:<[email protected]>...
I believe the problem is that 6.1 was released before J2EE 1.3 was final
and the EJBException serialversionuid changed. The easiest fix is to
take the EJBException class from 7.0 and put it in front of the 6.1
classpath.
-- Rob
Jim Cross wrote:
We are running two versions of WL and need to run the GUI part of App
on 7.0 and the business part on 6.1.
We get an exception on 6.1 but in handling the exception on 7.0 we get
the following error:
java.io.InvalidClassException: javax.ejb.EJBException; Local class not
compatibl
e: stream classdesc serialVersionUID=-9219910240172116449 local class
serialVers
ionUID=796770993296843510
Sure enough the EJBException class on the different servers have
different serial version numbers. Of course, the root cause is
something else but we need to be able to handle exceptions throw from
one to another.
Any ideas on the best way to handle this?