Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3D652507.7020608@verizon.net>
Date: Thu, 22 Aug 2002 13:53:11 -0400
From: Vadim Gritsenko <vadim.gritsenko@verizon.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.1b) Gecko/20020721
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: BUG: SiteMapSource lastModificationDate
References: <CC92E7C2663B1D498A745BD686C45E1F090648@exch2000.cti2.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Amir Rosen wrote:

>Hi,
>
>lastModificationDate for SiteMapSource is computed as hashing of the 
>string representations (toString()) of the event pipeline cache key 
>and validity. (I'm talking 2.0.3-branch)
>
>This breaks all the CacheValidity functionality when using internal
>requests.
>
>This implies that:
>cacheValidity1.isValid(cahceValidity2) 
>iff
>cacheValidity1.toString().equals(cacheValidity2.toString())
>
>Any non trivial cacheValidity object cann't work with this mechanism.
>For example DeltaTimeCacheValidity doesn't work in internal requests.
>(ParametersCacheValidity may work but it relies on the toString()
>implementation of java.util.Map)
>
>More than that, this contract is not documented anywhere, at least not
>in CacheValidity interface where it should. (I wasted two days debugging
>my system because of that).
>

It was documented in todo.xml.


>How do you think this mechanism can change ?
>Is there something planned for 2.1 ?
>

That's was one of the reasons for 2.1


Vadim


>Please, document this !!
>
>
>
>Thanks,
>
>Amir Rosen
>CTI Squared
>amir@cti2.com
>+972-9-9605200 (258)
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org