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/17 07:28:13 UTC

Re: There are no long lived serialized objects in Cocoon (was Re: svncommit: r124693)

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