If we had a minor release that is drop in replacement. Then currently it really works if we didn't had the uid it is really possible
that all session couldn't get read back in because of a method change somewhere in a component.
johan
On 2/12/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
No because we constantly have serialization exceptions that shouldn't be there.
It is a recommended thing to have youre own uid if you read the javadocs on them.
As i said the jvm is just to safe.. It uses methods and inner classes in the computation. That is just stupid in my eyes
because the only thing that really changes an object are the fields.
If we didn't have them i constantly have serialization problems.
I agree that for wicket it isn't that much a problem because most likely only one jvm is used.
But for example if a cluster is set up and not everywhere the exact same jvm is used it could be problems
Or if we want to upgrade the servers jvm but we want to keep the session after restart..
So having them is much much better then not having them.
johanOn 2/12/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote:the jvm automatically maintains them :)
-Igor
On 2/11/06, Jesse Sightler <[EMAIL PROTECTED] > wrote:I tend to agree... unless someone can come up with an automated way to maintain them, they should probably simply be removed. I tend to think the impetus for this was the silly compiler warning as well...
--
Jess
http://www.jroller.com/page/jsight/
On 2/11/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote:but the default is /safer/ because the jvm will create a unique one. i believe the only reason we added this was because someone did not like the warnings in the IDE, i think that was a pretty poor reason. i would be for removing them.
-Igor
On 2/11/06, Johan Compagner <[EMAIL PROTECTED] > wrote:not it is not a stupid idea in my eys.
Just have them there and never touch them is much better then not have them.
Because of the default behaviour of serialization which is in my eyes must the 'safe'
johanOn 2/11/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote:is there an automatic way to bump them up? there are thousands of them everywhere. i am not going to spend my time doing that by hand, i said in the first place it was a stupid idea to require them.
-Igor
On 2/11/06, Johan Compagner <[EMAIL PROTECTED] > wrote:
I think we need to add the following to this list:
- update the SerializationUUID's.
Why?
1.2 isn't a drop in replacement anyway
And i like it more that the deserialization just tries to fill the object.
Just we must make sure if there is really an object that has now a new field that is pretty importand
to the object to function then we have to bump up the uid with one.
Currently i don't know one.
johan
