cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: [C2] ShowStopper (CachingStreamPipeline)
Date Fri, 04 May 2001 20:25:29 GMT


On Fri, 4 May 2001, Berin Loritsch wrote:

> Berin Loritsch wrote:
> >
> > I am going to check for Logger issues (i.e. Logger not set), but
> > if this is a configuration issue, all configuration items should
> > have a default.
>
> After looking into it, we had an issue where we were comparing against
> a null within the CompositeCacheValidity that came from the
> AbstractServerPage.

Oops, that's my fault (but I remember reading that generateValidity can
return a null to indicate not cachable).

>
> It had a method like this:
>
> /**
>  * Generate Cache Validity object
>  *
>  * @returns null if not Cacheable
>  */
> public CacheValidity generateValidity() {
>     return null;
> }

Yes, I've generaly made AbstractServerPage cacheable because XSP pages
cannot state if they want to be cacheable thus the only way is to make
the base class cacheable. But returning a null from the base method in
the abstract class makes it per default not cacheable.

I'll come up with a sample how you can take advantage of caching in a
XSP page soon (not yet ready samples here).

> The problem is that the class also declaired itself Cacheable.

Yup. Do you see another way to make XSP pages cacheable that making the
base class every XSP extends cacheable?

> I changed it to return an NOPCacheValidity object on default.

I'm not sure this is a good approach. After a look into NOPCacheValidity
it will state a valid cache entry whenever it is passed another instace
of NOPCacheValidity. But this is not what I wanted. To solve this I see
two ways:

1) create a NOTCacheValidity which always returns false.
2) check for a null returnd by generateValidity methods as stated in the
javadocs.

For 1) we have to change the javadocs from the Validity classes.
For 2) we have to make sure nulls are tested.

> I also changed the XSPGenerator class to return a
> TimeStampCacheValidity object.

IMHO this doesn't make any sense because the XSPGenerator extends
AbstractServerPage. The wrapper class around every generated XSP class
(the one that generates, loads, and invokes the generated XSP java
class) is the ServerPagesGenerator which extends from XSPGenerator.

The request from the CachingEventPipeline (generateKey and
generateValidity) to an XSP page goes through the ServerPagesGenerator
which delegate it to the loaded XSP page (and adds the filename to the
key returnd from the XSP page to make the returned key unique within the
loaded XSP page and not only within the ServerPagesGenerator (this is
because the CachingEventPipeline only sees the ServerPageGenerator as
being the component to cache and not the underlying XSP pages which are
themself different components).

Giacomo

>
> After extensive testing I no longer get the error.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>


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


Mime
View raw message