Re: svn commit: r124693 - in cocoon/branches/BRANCH_2_1_X/src: blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication /configurationblocks/axis/java/org/apache/cocoon/components/axis/provi ders blocks/forms/java/org/apache/cocoon/forms/eventblocks/forms/java/org/a pache/cocoon/forms/flow/javascript blocks/forms/java/org/apache/cocoon/forms/flow/javascript/v2blocks/for ms/java/org/apache/cocoon/forms/formmodel blocks/paranoid/java/org/apache/cocoon/servletblocks/scratchpad/java/o rg/apache/cocoon/components/flow/javascript/fom blocks/scratchpad/java/org/apache/cocoon/generationblocks/web3/java/or g/apache/cocoon/components/web3/impl java/org/apache/cocoon/components/flow/javascript/fomjava/org/apache/c ocoon/servlet

[Niclas Hedhman <ni...@hedhman.org>]

On Saturday 15 January 2005 04:32, Antonio Gallardo wrote:
> I am also planning to add Read/Write Object methods on some of this
> classes.

Serialization is often taken too lightly, and Sylvain and Vadim are both 
expressing this somewhat indirectly.

Serialization *must* be considered a public interface, IF you expect different 
versions of the application to co-exist with each other, OR that the 
serialized data is expected to survive from one version to the next.

The "public interface" aspect should then be viewed in the exact same light as 
a public Java interface/class, which Cocoon has plenty. You can not go about 
and change them friviously, even if the change doesn't break the Cocoon 
distro itself. Such changes are not happening, not because people can't do 
them, but because they know how it must be dealt with.
Serialization is not a technical problem, it is a people problem (just like 
the public interfaces) and the best guards against improper use, I think, is 
education, peer-review and tests.


Cheers
Niclas

Re: svn commit: r124693 -

[Sylvain Wallez <sy...@apache.org>]

Niclas Hedhman wrote:

>On Saturday 15 January 2005 05:56, Antonio Gallardo wrote:
>  
>
>>now I am confused. 
>>    
>>
>
>Sorry :o(
>  
>
>>Need I revert the changes? 
>>    
>>
>
>Look at your use-case; Will the serialized data be used by more than one 
>versioned instance of Cocoon (for instance, RMI between two Cocoons), OR 
>persisted to survive an upgrade of a Cocoon version?
>
>If not, then I suggest that no need to bother with serialVersionUID nor 
>readObject/writeObject (except for that fact that both makes serialization 
>faster).
>
>If so, you need to make an active effort to keep serialization compatibility, 
>just like a public interface/class elsewhere.
>
>
>Does this answer it?
>  
>

Yes :-)

Sylvain

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

Re: svn commit: r124693 -

[Antonio Gallardo <ag...@agssa.net>]

Hi Niclas:

Thanks for the answer Niclas! It helped.

I was thinking about our users (as community) too. The use-case cited by
you could be a real situation for someone else.

I understood that serialVersionUID is not a performance improvement.
Because JVM caches the autogenerated serialVersionUID after computing it
the first time.

The read/write Object () could help us. And this should be something
important for us.

All in all, I think I will revert the changes to avoid more overhead about
this topic. Maybe in the next months, we could find out better
understanding of this and how affect cocoon after all.

I will start to revert the changes now, it is just few lines of code away.
;-)

Thanks for the comments.

Best Regards,

Antonio Gallardo

Re: svn commit: r124693 -

[Niclas Hedhman <ni...@hedhman.org>]

On Saturday 15 January 2005 05:56, Antonio Gallardo wrote:

> now I am confused. 

Sorry :o(

> Need I revert the changes? 

Look at your use-case; Will the serialized data be used by more than one 
versioned instance of Cocoon (for instance, RMI between two Cocoons), OR 
persisted to survive an upgrade of a Cocoon version?

If not, then I suggest that no need to bother with serialVersionUID nor 
readObject/writeObject (except for that fact that both makes serialization 
faster).

If so, you need to make an active effort to keep serialization compatibility, 
just like a public interface/class elsewhere.


Does this answer it?


Cheers
Niclas

Re: svn commit: r124693 - in cocoon/branches/BRANCH_2_1_X/src: blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication /configurationblocks/axis/java/org/apache/cocoon/components/axis/prov i ders blocks/forms/java/org/apache/cocoon/forms/eventblocks/forms/java/org/a pache/cocoon/forms/flow/javascript blocks/forms/java/org/apache/cocoon/forms/flow/javascript/v2blocks/for ms/java/org/apache/cocoon/forms/formmodel blocks/paranoid/java/org/apache/cocoon/servletblocks/scratchpad/java/o rg/apache/cocoon/components/flow/javascript/fom blocks/scratchpad/java/org/apache/cocoon/generationblocks/web3/java/or g/apache/cocoon/components/web3/impl java/org/apache/cocoon/components/flow/javascript/fomjava/org/apache/c ocoon/servlet

[Antonio Gallardo <ag...@agssa.net>]

On Sab, 15 de Enero de 2005, 7:29, Niclas Hedhman dijo:
> On Saturday 15 January 2005 04:32, Antonio Gallardo wrote:
>> I am also planning to add Read/Write Object methods on some of this
>> classes.
>
> Serialization is often taken too lightly, and Sylvain and Vadim are both
> expressing this somewhat indirectly.
>
> Serialization *must* be considered a public interface, IF you expect
> different
> versions of the application to co-exist with each other, OR that the
> serialized data is expected to survive from one version to the next.
>
> The "public interface" aspect should then be viewed in the exact same
> light as
> a public Java interface/class, which Cocoon has plenty. You can not go
> about
> and change them friviously, even if the change doesn't break the Cocoon
> distro itself. Such changes are not happening, not because people can't do
> them, but because they know how it must be dealt with.
> Serialization is not a technical problem, it is a people problem (just
> like
> the public interfaces) and the best guards against improper use, I think,
> is
> education, peer-review and tests.

now I am confused. Need I revert the changes?

Best Regards,

Antonio Gallardo