Re: Is serialVersionUID really required?
not that importand it is just easier to cluster over different jvms (which doesnt happen a lot) but it is also easier to upgrade an existing code. Because the generated serialVersionUID does change for the most stupid ways (i guess they have to do that but most of the time i don;t care if i added a method) without the id serialization just breaks (can't deserialize) just way more often johan On Thu, Feb 14, 2008 at 4:09 PM, Wang, Yuesong [EMAIL PROTECTED] wrote: Hi, In theory, all Serializable classes should have a serialVersionUID, but to provide one to every annonymous inner class used everywhere in a Wicket app is just too much. So I decided to turn off that warning in Eclipse, and not to use serialVersionUID any more, but what is the implication? For example, will I run into any problem during deployment/undeployment? What about clustering? Thanks, Yuesong
RE: Is serialVersionUID really required?
Johan, Thanks for the reply. Just need some further comfirmation. Here is my scenario: 1) The app is packaged in a single war. 2) No distributed deployment - everything is on the app server (Tomcat 6.0). 3) Only user agent is web browser. No remote client (RMI, java web start etc.). 4) Same JVM across all servers in cluster. 5) When deploying a new release, all servers will be stopped/undeployed/deployed/started at the same time. Is that enough to avoid potential serialization issues that may be caused by not supplying serialVersionUID? Yuesong -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 11:06 AM To: users@wicket.apache.org Subject: Re: Is serialVersionUID really required? not that importand it is just easier to cluster over different jvms (which doesnt happen a lot) but it is also easier to upgrade an existing code. Because the generated serialVersionUID does change for the most stupid ways (i guess they have to do that but most of the time i don;t care if i added a method) without the id serialization just breaks (can't deserialize) just way more often johan On Thu, Feb 14, 2008 at 4:09 PM, Wang, Yuesong [EMAIL PROTECTED] wrote: Hi, In theory, all Serializable classes should have a serialVersionUID, but to provide one to every annonymous inner class used everywhere in a Wicket app is just too much. So I decided to turn off that warning in Eclipse, and not to use serialVersionUID any more, but what is the implication? For example, will I run into any problem during deployment/undeployment? What about clustering? Thanks, Yuesong - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is serialVersionUID really required?
if you redeploy a new version where you did some changes in components that would now generate another id then the sessions that are on disk cant be loaded anymore so you loose your sessions if you had an id. And you dont change it because you want to be able to deserialize because you dont added a field or what ever and you know that the deseralized object works perfectly with the new object then it can be loaded in and you wont loose sessions johan On Thu, Feb 14, 2008 at 5:23 PM, Wang, Yuesong [EMAIL PROTECTED] wrote: Johan, Thanks for the reply. Just need some further comfirmation. Here is my scenario: 1) The app is packaged in a single war. 2) No distributed deployment - everything is on the app server (Tomcat 6.0). 3) Only user agent is web browser. No remote client (RMI, java web start etc.). 4) Same JVM across all servers in cluster. 5) When deploying a new release, all servers will be stopped/undeployed/deployed/started at the same time. Is that enough to avoid potential serialization issues that may be caused by not supplying serialVersionUID? Yuesong -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 11:06 AM To: users@wicket.apache.org Subject: Re: Is serialVersionUID really required? not that importand it is just easier to cluster over different jvms (which doesnt happen a lot) but it is also easier to upgrade an existing code. Because the generated serialVersionUID does change for the most stupid ways (i guess they have to do that but most of the time i don;t care if i added a method) without the id serialization just breaks (can't deserialize) just way more often johan On Thu, Feb 14, 2008 at 4:09 PM, Wang, Yuesong [EMAIL PROTECTED] wrote: Hi, In theory, all Serializable classes should have a serialVersionUID, but to provide one to every annonymous inner class used everywhere in a Wicket app is just too much. So I decided to turn off that warning in Eclipse, and not to use serialVersionUID any more, but what is the implication? For example, will I run into any problem during deployment/undeployment? What about clustering? Thanks, Yuesong - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
