that sounds good.
is there a utility out there that will rip through a bunch of source/class files and update the serialVerisonUID fields? this would be really useful.
Christopher Turner wrote:
As far as I am aware there is a requirement that all machines in a cluster are running exactly the same code on the same server version under the same JVM version (you'd be pretty foolish to try to do otherwise). Therefore I can't see any reason to require the serialVersionID functionality in order to support clustering.
The only potential use I can think of is related to session recovery functionality as implemented by Tomcat (and some other app servers). Basically when Tomcat shuts down or before an application is redeployed it can serialise all of the current sessions to disk. Then when it restarts or the updated application is redepolyed the session objects can be deserialised and technically the users should be able to carry on exactly where they left off if the data from the session classes has not been changed. There is an argument that therefore any classes in the session should have the serialVersionID value set so that you can always upgrade the class logic without changing the serialized data image (i.e. only change serialVersionID when the attributes of the class change). And thus you actually support hot deploy with the possibility of sessions being retained across the deployment.
However, I can't think of any cases where I have worked on a web application where a new version hasn't altered some element of the UI. Therefore I think in most cases Wicket applications will always have different session data for each new deployment.
Conclusion: It's probably worth keeping the serialVersionID fields for any object that gets into the session, giving them good values before 1.0 and then making sure these values are updated every time the attributes of a class are modified. Even if noone ever uses this feature it's nice to be able to say that Wicket supports hot-deployment in cases where the page components have not changed.
Regards, Chris
>
>
> Eelco Hillenius wrote:
>
> > It has been bugging me as well. Theoretically, it just might be an
> > issue - though as currently, with changes in classes the
> ids are not
> > updated, this would give problems anyway, but practically,
> I would be
> > surprised if anyone came up with a good reason to do this. Except
> > maybe, as Johan put it (we had this discussion offline), it is good
> > practice to have the id on all serializable classes.
>
> this is true. but if nobody is really updating the values or
> thinking
> about when compatibility is broken, what's the value?
>
> >
> > Eelco
> >
> > Jonathan Locke wrote:
> >
> >>
> >> i was just adding a serialVersionID to the Index page in the
> >> QuickStart project when I realized...
> >>
> >> why are we adding these? serialVersionID is generally for
> persistent
> >> serialized data. since the only reason
> >> half our classes are serializable is to allow clustering, it seems
> >> useless to advise users to do this. it's a pain
> >> and there's no good reason for it... unless there are app
> containers
> >> that deal with class versioning issues
> >> (maybe they can deal with rolling out new code on only some of the
> >> servers in a cluster...?)... chris, do
> >> you have any thoughts here?
> >>
> >> jon
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> SF email is sponsored by - The IT Product Guide
> >> Read honest & candid reviews on hundreds of IT Products from real
> >> users. Discover which products truly live up to the hype. Start
> >> reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396 <http://ads.osdn.com/?ad_id=6595&alloc_id=14396>> &op=click
> >>
> _______________________________________________
>
> >> Wicket-develop mailing list [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real
> > users. Discover which products truly live up to the hype. Start
> > reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click <http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click>
> > _______________________________________________
> > Wicket-develop mailing list [email protected]
> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from
> real users. Discover which products truly live up to the
> hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396 <http://ads.osdn.com/?ad_id=6595&alloc_id=14396>> &op=click
>
> _______________________________________________
>
> Wicket-develop mailing list [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
