cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject There are no long lived serialized objects in Cocoon (was Re: svn commit: r124693)
Date Sat, 15 Jan 2005 09:32:09 GMT
Antonio Gallardo wrote:

>On Vie, 14 de Enero de 2005, 16:59, Sylvain Wallez dijo:
>  
>
>>Vadim Gritsenko wrote:
>>    
>>
>>>Antonio Gallardo wrote:
>>>      
>>>
>>>>Please give me a little time to fix all the serialization changes. I am
>>>>currently using the BRANCH head in development this version and I am
>>>>checking if everything is working good.
>>>>
>>>>Anyway this could not harm. It is just a line on each class and we can
>>>>remove them if not needed before releasing.
>>>>        
>>>>
>>>No problem, take your time. Just out of curiosity, what is your
>>>scenario which requires serialization?
>>>      
>>>
>>Yes, please explain, Antonio.
>>
>>Also, and we discussed this already not long ago [1], serial uid is
>>useful for long-lived serialized objects where there is a chance that
>>the class changes between serialization and deserialization. What in
>>Cocoon justifies this?
>>    
>>
>
>Shared remote cache. In some cases, they can use diferent java versions
>across machines and the troubles can be raisen.
>  
>

What shared remote caches? Do you have that already? And the problem 
here is not having different *java* versions, but different *cocoon* 
versions using the same hypothetical remote cache. And that would seem a 
very bad thing to me to have different Cocoon version share their 
caches. Not only because of class versions, but also because different 
versions may also mean different sitemaps, different XSLs, etc, leading 
the cached content to be actually different for the different Cocoon 
instances.

>>Furthermore, Niclas' explanation that having a serialVersionUID leads to
>>newly added fields to have no value seems particularily dangerous to me
>>if we don't take special care about this as it can lead to weird errors.
>>    
>>
>
>Nope. Because as you explained in your mail, we are not persisting for too
>long time. We will not take an "obscure failure" error. The weird errors
>are on the code without serialversionUID, because if you already have a
>Object cache cache and add a method to a serialiable class class there
>start the problems.
>  
>

That's exactly the point: when do we have the probability that the 
pesistant cache is reused by a different version of Cocoon? Either 
during development or when a production machine is upgraded.

In both cases, the persistent cache *should be cleared*. Actually we 
should even to it within Cocoon.initialize().

So, back to the uid problem, such class version mismatches aren't to be 
considered as nominal conditions, as is the case with distributed 
applications. Cocoon is not a distributed system and is not supposed to 
have long-lived persistent data.

Furthermore, the cache is a *cache* and therefore the system doesn't 
require some data to exist there.

That's why I prefer not having uids, and not having to be careful about 
updating them or *maintaining* readObject/writeObject methods just for 
the exceptional condition of stop/updgrade/restart.

>>So I am -1 on adding serialVersionUIDs to Cocoon classes unless there is
>>a good reason for this.
>>    
>>
>
>First, I am just trying to close posible "collateral damages". I am just
>adding the points over the "i"es here.
>
>If we have made the decisions to serialize some classes, we need to finish
>the work to avoid potential problems.
>

Sorry, I should have missed that: when have we made such decision? Can 
you point me to the archives?

>And this is what I am doing now,
>just trying to close this doors by assuring that the serialization is done
>as is recommended by people that has more years working in java than me.
>
>What I understood is:
>
>If the class implements the Serializable interface, but does not define a
>serialVersionUID field then a change as simple as adding a reference to a
>.class object will add synthetic fields to the class, which will
>unfortunately change the implicit serialVersionUID (e.g., adding a
>reference to String.class will generate a static field
>class$java$lang$String). Also, different source code to bytecode compilers
>may use different naming conventions for synthetic variables generated for
>references to class objects or inner classes. We need toconsider adding an
>explicit serialVersionUID to ensure interoperability of Serializable
>across versions.
>
>Then reading from Effective Java from Joshua Bloch pag 214, 2nd paragraph:
>
><snip>
>A simple example of the constraints on evolution that accompany
>serializability concerns stream unique identifiers, more commonly known as
>serial version UIDs. Every serializable class has a unique identification
>number associated with it.
></snip>
>
>That means that no matter we do we already have one there!
>  
>

Yes, but it is automatically generated for us, which is good as we don't 
need long lived serialized objects, and therefore don't have to consider 
class compatibility issues at the serialization level. Let just the JDK 
produce the uid for us and throw a nice java.io.InvalidClassException if 
ever, by mistake, we try to deserialize something that we should not.

Again, Cocoon isn't a distributed system and sharing serialized objects 
between different version (either across space or time) is not a concern 
for Cocoon.

<snip/>

>I am also planning to add Read/Write Object methods on some of this classes.
>  
>

That's precisely the additional job I want us to avoid to maintain.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message