cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject 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
Date Wed, 12 Jan 2005 20:02:03 GMT
On Mie, 12 de Enero de 2005, 8:14, Vadim Gritsenko dijo:
> wrote:
>> Author: antonio
>> Date: Sat Jan  8 16:35:26 2005
>> New Revision: 124693
> Hi Antonio,

Hi Vadim,

Thanks for reviewing.

I am trying to fix the serialization problems in Cocoon. It is still a
work in progress. ;-)

> What logic have you used to select classes for adding serialVersionUID?

The Serialization is not perfect. Between Java VM versions (even from the
same provider) are differents. We are still supporting java 1.3 and this
was the main reason to add the serialVersionUID.

>> URL:
>> Log:
>> Add serialVersionUID
>> Modified:
>>    cocoon/branches/BRANCH_2_1_X/src/blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication/configuration/
>>    cocoon/branches/BRANCH_2_1_X/src/blocks/axis/java/org/apache/cocoon/components/axis/providers/
>>    cocoon/branches/BRANCH_2_1_X/src/blocks/scratchpad/java/org/apache/cocoon/generation/
>>    cocoon/branches/BRANCH_2_1_X/src/blocks/web3/java/org/apache/cocoon/components/web3/impl/
> Even though above classes are Serializable, none of those classes have
> witeObject / readObject methods. Next change to any of those classess will
> cause
> exceptions during serialization, if somebody to try it. serialVersionUID
> should
> be removed. The only situation when it must be added back is when there is
> a
> conscious effort to make different versions of the class to have
> compatible disk
> format.

Yep. I am planning to add the missing methods if needed.

>>    cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript/v2/
> These classes, even though super class is marked as Serializable, have non
> transient member storing instance(s) of the non serializable classes, so
> serialVersionUID here has no sense and should be removed. Any attempt to
> serialize / deserialize these objects will cause system to fail.

Let review this.

>>    cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/event/
>>    cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/formmodel/
> Here serialVersionUID makes no harm, so probably it can be left in.
>>    cocoon/branches/BRANCH_2_1_X/src/blocks/paranoid/java/org/apache/cocoon/servlet/
>>    cocoon/branches/BRANCH_2_1_X/src/blocks/scratchpad/java/org/apache/cocoon/components/flow/javascript/fom/
>>    cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/javascript/fom/
>>    cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/servlet/
> Same situation as with ScriptableWidget. Nothing good will happen after
> serialization.

I will review this too.

> Please revert.

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.


Best Regards,

Antonio Gallardo

View raw message