Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <33197.10.0.0.5.1105943293.squirrel@www.agssa.net>
In-Reply-To: <41E8E319.8090009@apache.org>
References: <20050109003528.55029.qmail@minotaur.apache.org>      
    <41E530AB.6040504@reverycodes.com>   
    <36839.10.0.0.5.1105560123.squirrel@www.agssa.net>   
    <41E59299.6050908@reverycodes.com> <41E84ED4.5090603@apache.org>
    <34785.10.0.0.5.1105763563.squirrel@www.agssa.net>
    <41E8E319.8090009@apache.org>
Date: Mon, 17 Jan 2005 00:28:13 -0600 (CST)
Subject: Re: There are no long lived serialized objects in Cocoon (was Re:
     svncommit: r124693)
From: "Antonio Gallardo" <agallardo@agssa.net>
To: dev@cocoon.apache.org
User-Agent: SquirrelMail/1.4.3a-6.FC2
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

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