serialVersionUID and NoClassDefFoundError
Hi, I was encountering a problem this week that I luckily managed to solve. However, I thought it might be useful to share my knowledge about this on the mailing list. The problem involves an AxisFault in my web service, which was apparently caused by a NoClassDefFoundError. For the impatient: the short solution is, to always define "private static final long serialVersionUID" to a meaningful value. For anyone who's interested, this is what happened: System: - axis2 1.4 (also used 1.3) - Java JDK 1.6 update 6 - tomcat 6.0.16, with axis2.war running as a web application - linux (some old fedora version with kernel 2.4.20-31.9) I am testing axis2 for a scenario where clients pass TV metadata via SOAP to a web server, which collates it and hopefully does interesting things with it. On the server side I need to convert from the databinding classes to our own custom Java classes, because further encoding steps depend on them. The converter class ADBBean2TVAnytimeAPI was put into a larger converter library, which had to be linked against some of the axis2 jars and some of the code that was generated from the WSDL. A colleague had started this project and written the WSDL and also decided to generate and compile client-side and server-side code independently into different directories (autogen/client and autogen/service). Both directories would contain certain common files that were needed on both sides (most importantly, the ADBBeans). The client-side JAR file was used by the converter library. I implemented the additional server-side code that would contain the actual application logic (for which the new converter class was needed). Then I deployed the compiled code as an axis2 service into tomcat. When I tried to send data from the client to the server, it would fail on the server side with the following error: [ERROR] tva/cri/ResultType java.lang.NoClassDefFoundError: tva/cri/ResultType at bbc.rd.tvadb.converter.ADBBean2TVAnytimeAPI.convert(ADBBean2TVAnytimeAPI.java:90) at bbc.rd.tvadb.converter.ADBBean2TVAnytimeAPI.convert(ADBBean2TVAnytimeAPI.java:55) at bbc.rd.tvadb.server.database.TimedResult.(TimedResult.java:72) at bbc.rd.tvadb.server.database.ServerCRIDatabase.add(ServerCRIDatabase.java:161) at bbc.rd.tvadb.server.database.ServerCRIDatabase.update(ServerCRIDatabase.java:134) at uk.co.bbc.rd.metadataInterchangeService.MetadataInterchangeServiceSkeleton.CRI_Resolutions_Operation(MetadataInterchangeServiceSkeleton.java:765) at uk.co.bbc.rd.metadataInterchangeService.MetadataInterchangeServiceMessageReceiverInOut.invokeBusinessLogic(MetadataInterchangeServiceMessageReceiverInOut.java:84) at org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40) at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:100) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275) at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:131) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:856) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:565) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1509) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.ClassNotFoundException: tva.cri.ResultType at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1360) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1206) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) ... 26 more I wasn't sure what to make of this first, as the server-side code that was packaged in the axis2.war DID contain all the necessary classes. Also, it had worked before. I was sure that it wasn't a classpath issue (although the error sounds like it was). The only change was, that
inserting serialVersionUID?
Title: inserting serialVersionUID? Hi all, Is it possible to tweak the wsdl2java process to insert a specified serialVersionUID? I’m thinking about serializing some objects and am concerned about version compatibility. Thanks John Gregg Application Systems Engineer Wells Fargo Private Client Services Technology
Re: serialVersionUID?
you can tell eclipse to ignore that warning in preferences->java->compiler->Errors/Warnings->Potential Programming Problems. If you don't want to ignore, then you'll have to hit "quick fix" like crazy on your problems list :D On 7/19/05, Kador, Daniel <[EMAIL PROTECTED]> wrote: > Hi, > > I've noticed that Axis-generated classes don't have a private static > final long serialVersionUID member. This isn't an error, but Eclipse > reports it with a compile warning. I've researched a little and found > out that having this member is not required, but is highly recommended > to ensure interopability while serializing on different platforms. > > I'd like to get rid of the warnings. Eclipse will generate it for me, > but I have well over 100 classes with this problem, so it'd be great if > I could find an automatic fix. > > Thanks, > Dan > -- Javier Gonzalez Nicolini
Re: serialVersionUID?
It's not a problem we need to worry about, Dan because XML decouples different systems. When a serialVersionUID is not provided for a class, the Java subsystem generates one based upon the class content. Hence, when the content changes, e.g. by adding a field, the auto-generated serialVersionUID changes. This tells Java's serialization mechanism that different versions of the same class are not compatible. By providing your own serialVersionUID for a class you can ensure that new versions of a class are compatible with older versions by retaining all the original fields (even if there are some you no longer use) and by initializing new fields (so that deserialization from old classes to new classes still works). This becomes fraught when dealing with obfuscation and nested classes. Another source of potential problems arises when dealing with classes that serialize/deserialize across networks, as in RMI. Thankfully, web services eliminate these problems because we never .serialize/deserialize classes across networks, we just pass XML. Hence, so long as XML Schemas are in synch. between different systems, we can forget about serialVersionUID. Jeff Lawson - Original Message - From: "Kador, Daniel" <[EMAIL PROTECTED]> To: Sent: Tuesday, July 19, 2005 3:30 PM Subject: serialVersionUID? > Hi, > > I've noticed that Axis-generated classes don't have a private static > final long serialVersionUID member. This isn't an error, but Eclipse > reports it with a compile warning. I've researched a little and found > out that having this member is not required, but is highly recommended > to ensure interopability while serializing on different platforms. > > I'd like to get rid of the warnings. Eclipse will generate it for me, > but I have well over 100 classes with this problem, so it'd be great if > I could find an automatic fix. > > Thanks, > Dan > >
serialVersionUID?
Hi, I've noticed that Axis-generated classes don't have a private static final long serialVersionUID member. This isn't an error, but Eclipse reports it with a compile warning. I've researched a little and found out that having this member is not required, but is highly recommended to ensure interopability while serializing on different platforms. I'd like to get rid of the warnings. Eclipse will generate it for me, but I have well over 100 classes with this problem, so it'd be great if I could find an automatic fix. Thanks, Dan
