How do I correct a Java LinkageError exception?

I am developing an application for WebSphere 6.1 which uses a Java servlet. Within my servlet, I have defined a serial vesion ID of 1L. Upon deploying and running my application, I am receiving a LinkageError of the following type (from the server log):

[5/9/11 15:14:26:868 EDT] 0000001c WebApp        
E   [Servlet Error]-[ManageRecordsConsumerServlet]: java.lang.Exception: 
java.lang.LinkageError: LinkageError while defining class: 
<redacted>.docindexupdate.batch.servlet.ManageRecordsConsumerServlet
Could not be defined due to: (<redacted>/docindexupdate/batch/servlet
/ManageRecordsConsumerServlet) class name must be a string at offset=2074
This is often caused by having a class defined at multiple
locations within the classloader hierarchy.  Other potential causes
include compiling against an older or newer version of the class
that has an incompatible method signature.

I'm not sure what the issue is. I was seeing this previously before defining a serial version uid 开发者_如何学Cand figured that by defining that and being consistent, future updates to the class file would run successfully. There are no errors during compilation or deployment to the server. Is it possible that an older version of the servlet is cached somewhere on the WebSphere instance (I am only deploying on my dev machine at the moment)?

The

 class name must be a string at offset=2074

line is also confusing.

---

I am suspecting you have a jar that is being loaded in two different classloaders. By that I mean, your websphere server on startup loads that jar or has an endorsed directory with that jar. Also your EAR you are deploying has that jar in its lib. The two can conflict at runtime

What I would suggest is to find out which jar ManageRecordsConsumerServlet belongs to and either remove it from your EAR lib or your Websphere endorsed lib (best would be your EAR lib).

---

It may be versioning, but I don't thing so.

When two classes loaded by different classloader, a ClassNotFoundException is normally thrown.

When a class is passed over a wire/loaded from disk cache, VersionMismatchException is normally thrown.

When a class with different method signatures is used, NoSuchMethodError or alike is thrown.

I think this case is a corrupted class file. Could be corrupted in cache or in the JAR.