You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Antonio Gallardo <ag...@agssa.net> on 2005/01/12 21:02:03 UTC
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
On Mie, 12 de Enero de 2005, 8:14, Vadim Gritsenko dijo:
> antonio@apache.org 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: http://svn.apache.org/viewcvs?view=rev&rev=124693
>> Log:
>> Add serialVersionUID
>> Modified:
>> cocoon/branches/BRANCH_2_1_X/src/blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication/configuration/HandlerConfiguration.java
>> cocoon/branches/BRANCH_2_1_X/src/blocks/axis/java/org/apache/cocoon/components/axis/providers/AvalonProvider.java
>> cocoon/branches/BRANCH_2_1_X/src/blocks/scratchpad/java/org/apache/cocoon/generation/RequestParameterGenerator.java
>> cocoon/branches/BRANCH_2_1_X/src/blocks/web3/java/org/apache/cocoon/components/web3/impl/Web3Properties.java
>
> 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/ScriptableWidget.java
>> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript/v2/ScriptableWidget.java
>
> 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/ProcessingPhase.java
>> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/formmodel/WidgetState.java
>
> 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/ParanoidCocoonServlet.java
>> cocoon/branches/BRANCH_2_1_X/src/blocks/scratchpad/java/org/apache/cocoon/components/flow/javascript/fom/AO_FOM_Cocoon.java
>> cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java
>> cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/servlet/CocoonServlet.java
>
> 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.
WDYT?
Best Regards,
Antonio Gallardo
Re: svn commit: r124693 -
Posted by 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 -
Posted by 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 -
Posted by 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
Posted by 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
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
Posted by 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: There are no long lived serialized objects in Cocoon (was Re:
svncommit: r124693)
Posted by Antonio Gallardo <ag...@agssa.net>.
On Sab, 15 de Enero de 2005, 3:32, Sylvain Wallez dijo:
> Antonio Gallardo wrote:
> What shared remote caches? Do you have that already?
Apache JCS allows to setup remote cache.
> 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.
Not only different cocoons version. I read that diferent JVM versions use
diferents methods to compute the serialVersionUID for the same version of
a class. As a sample I think there was JVM 1.3 vs. JVM 1.4, IBM and GNU
also compute it diferent too.
>>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?
I can point you to the code that we ship and shipped before. I don't know
when that was decided, but the code is there. :-D
>>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.
See this:
http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4651879
Closed in 1.4 but seems to live in 1.3.
> 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.
I was not talking about Cocoon. But it could be used in a distributed
system too or not? After all, Cocoon is a servlet.
> <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.
Niclas told that writing this methods we can improve the cocoon
performance, but I am not sure of that. Well, in any case, I already
reverted the changes.
Best Regards,
Antonio Gallardo
There are no long lived serialized objects in Cocoon (was Re: svn
commit: r124693)
Posted by Sylvain Wallez <sy...@apache.org>.
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 }
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
Posted by Antonio Gallardo <ag...@agssa.net>.
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.
> 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.
> 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. 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!
<snip>
If you don't specify the identify the identification number explicitly by
declaring a private static final long field name called serialVersionUID,
the system automatically generates it by applying a complex deterministic
procedure to class. The automatically generated value is affected by the
class's name, the names of the interfaces it implements, and all of its
public and protected members. If you change any of this things in any way,
for example, by adding a trivial convenience method, the automatically
generated serial version UID changes. If you fail to declare an explicit
serial version UID, compatibility is broken.
</snip>
I am also planning to add Read/Write Object methods on some of this classes.
Best Regards,
Antonio Gallardo
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
Posted by Sylvain Wallez <sy...@apache.org>.
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?
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.
So I am -1 on adding serialVersionUIDs to Cocoon classes unless there is
a good reason for this.
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110096211520254&w=2
--
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 - 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
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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?
Vadim