Okay I understand everything you say, but I still think the ContentAggregator code has a problem.
> It's not second one, it's *the* *same* object. Equal keys == same > object. See cacheable.xsp to get an idea, it shows how with > the help of > a single XSP you can create multiple objects (with different > keys). In > cacheable.xsp, every different value of the request parameter 'param' > will create different object (in the cache). > ... > I think you had confusion here. Main point is: > Key identfies object, > Validity represents *status* of this object (changed - need to be > re-generated / not changed - can serve from cache). > > Thus, to create several objects, simply generate different keys. I understand the code in cacheable.xsp; but even if cacheable.xsp has multiple keys, those keys are not taken into account when cacheable.xsp is put into an aggregation--ContentAggregator will always generate the same key, no matter what cacheable.xsp's generateKey() function is! (Because cacheable.xsp's generateKey() is totally ignored by ContentAggregator's generateKey()). This is wrong. My change uses the (hash of the) xsp's validityObject instead of its key as a part of ContentAggregator's generateKey()--this is not so good, but I don't know how to get to the key from a SitemapSource. Still, I believe that the hash of the validityObject is better than what is there now! --Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
