On Tuesday, August 14, 2001, at 04:04 pm, Carsten Ziegeler wrote:
>> In SitemapSource.java are the lines:
>>
>>> // the event pipeline is cacheable
>>> // now calculate a last modification date
>>> String hashKey = pck.toString() + validity.toString();
>>> this.lastModificationDate = HashUtil.hash(hashKey);
>>
>> this is used in ProgramGeneratorImpl.java:
>>
>>> /*
>>> * FIXME: It's the program (not the instance) that must
>>> * be queried for changes!!!
>>> */
>>> if (programInstance != null &&
>>> programInstance.modifiedSince(source.getLastModified())) {
>>> // Release the component.
>>> release(programInstance);
>>
>> consequently, any use of the ServerPages Generator which takes an input
>> from within the sitemap (e.g. using a "cocoon:/" URI) will result
>> in (on a
>> practically random basis) certain XSP (et. al) pages being regenerated
>> over and over again, and will potentially prevent updated XSP (et. al)
>> from being properly regenerated.
>>
> Hm, that is true. The problem is that I don't saw any other way to
> implement the lastModificationDate for the SitemapSource than hashing
> the key.
> Usually this modification date is used in the caching algorithm
> and is there only tested against equal. So there this hack works.
>
> Any solution for this?
For the caching, I presume there is a mapping of hashKeys to
serializedResults. If this is true, then couldn't these also map to a
date-stamp of when the result was cached and have lastModificationDate =
lastCachedDate?
Stuart.
-------------------------------------------------------------------------
Stuart Roebuck [EMAIL PROTECTED]
Lead Developer Java, XML, MacOS X, XP, etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
