[ksgetting]

After I change one of my Java class files and start Tomcat to test, I sometimes see the error below. I have been running Project -> Clean against the dependent Java Project to correct this error. Am I doing anything wrong to cause this incompatible error? Most of the time, following this scenario shows no error.

Jun 20, 2005 9:13:03 AM org.apache.catalina.session.StandardManager doLoad
SEVERE: IOException while loading persisted sessions: java.io.InvalidClassException: planetj.magic.AbstractMagicRequest; local class incompatible: stream classdesc serialVersionUID = -7798396035073336948, local class serialVersionUID = 2677195490535841266
java.io.InvalidClassException: planetj.magic.AbstractMagicRequest; local class incompatible: stream classdesc serialVersionUID = -7798396035073336948, local class serialVersionUID = 2677195490535841266
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:463)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1521)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1521)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1521)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1521)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1521)
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)
——————————-
My profile is as follows:

What operating system and version are you running?
Windows XP, SP2

What Eclipse version and build id are you using? (Help > About Eclipse Platform)
Version: 3.0.2
Build id: 200503110845

– Was Eclipse freshly installed for MyEclipse?
Yes

– Are any other external plugins installed?
No

– How many plugins in the <eclipse>/plugins directory are like org.eclipse.pde.*
8

What MyEclipse version are you using? (Help > About Eclipse Platform > Features)
3.8.4

What JDK version are you using to run Eclipse? (java -version)
1.4.2 (compiler compliance level 1.3)

What JDK version are you using to launch your application server?
1.4.2

What steps did you take that resulted in the issue?
– Update a Java file
– Start Tomcat 5.0.28 server (for debug)

What application server are you using?
Tomcat 5.0.28

Are there any exceptions in the Eclipse log file? (<workspace>/.metadata/.log)
No

[Scott Anderson]

The problem is that one of the classes you’re recompiling is serializable but does not define it’s own SerialVersionUID field. Specifically, it looks like it’s this class or a class it uses (planetj.magic.AbstractMagicRequest). So, each time it’s compiled by a different JVM, a different SerialVersionUID can be generated. You can likely resolve the issue by either defining the SerialVersionUID, or by ensuring that both Eclipse and Tomcat are running with exactly the same JDK. The first will certainly work; the second may or may not.

[ksgetting]

Eclipse and Tomcat are both using the same JDK (1.4.2). I noticed that everytime I add a new method/remove a method from a serialized java class, stopping and restarting Tomcat results in this error:

SEVERE: Exception loading sessions from persistent storage
java.io.InvalidClassException: planetj.database.field.TimestampField; local class incompatible: stream classdesc serialVersionUID = 6809550477348184954, local class serialVersionUID = -2348657424995727019

If I stop and restart Tomcat again, the problem goes away. This is rather annoying to have to restart Tomcat twice. I checked the copy of the class file generated after compiling the java changes. The class file in my workspace and in Tomcat appears to be the same (same create time and size). We have quite a few serialized class files, so I’m not sure how practical it would be to add a “serialVersionUID” definition to each one. Shouldn’t the JVM be the same for compiling if Eclipse has not been restarted since the last compile?

[Riyad Kalla]

This isn’t surprising, you are changing the “shape” of the class which invalidates the serialVersionID you’ve given it. When Tomcat shuts down it’s persists it’s state, so when it is starting back up with your new class, it tries to restore the class state and barfs on itself.

I would suggest that if you are using an exploded deployment to a running Tomcat instance, and you haev your context set to reloadable, you shouldn’t need to be restarting Tomcat all the time.

[ksgetting]

I have been restarting Tomcat because it seems like whenever I add/remove a method, I’m usually “out-of-synch” with Tomcat. Is this normal? If so, is Tomcat 5.5 different/better in handling this. Or is there an easy way to just restart my application from Eclipse.

[Riyad Kalla]

If you are using a packaged deployment (create a WAR) then yes you are out of sync, if you use an exploded deployment *and* your context is set to be reloadable, Tomcat will reload your changes and MyEclipse will sync them out each time you save a file.

[ksgetting]

@support-rkalla wrote:

If you are using a packaged deployment (create a WAR) then yes you are out of sync, if you use an exploded deployment *and* your context is set to be reloadable, Tomcat will reload your changes and MyEclipse will sync them out each time you save a file.

In my Tomcat\conf\web.xml file, I have the servlet init-param set to reloadable (true). I don’t use a WAR file. In my web project preferences -> MyEclipse-Web -> Deployment, it’s set to “Use Smart Deployment for Dependent Java Projects” and “Jars exported from dependent projects” is checked. If I make changes that do not add or remove a method, my code stays in sync.

[leontee]

Hey ksgetting. I came across a similar problem when changing one of my javabean files and i wasn’t able to start my Jboss at all.

I worked around it by removing the temp files that Jboss uses to persist the system state. These were located under <jboss folder>\server\default\tmp\deploy. For safety, i simply moved the contents of this folder elsewhere first, and my Jboss started up successfully.

You were experiencing this problem a long time ago and this may not be of any use to you, but i hope that this post will help someone else running into the same problem as i did.

Cheers
Leon

[Author]

Posts