It is herewith confirmed that pipelinecompont.setup() is called before
constructCacheKey! (see CachingPipeline.setup().
The nullpointerexception I observed stemmed from a class inheritance
(forgot super.setup() in one of the participating generators).
Cheers,
Jos
On Tue, 2010-03-09 at 13:25 +0100, Jos Snellings wrote:
> Please put this message on hold. I might have expressed myself in haste.
> First I need to perform another test!
> Jos
> On Tue, 2010-03-09 at 13:17 +0100, Jos Snellings wrote:
> > Yes, Reinhard, I agree very much with the observation that everything
> > that influences the output must go in the cache key.
> > OK, I use the user group again, because I am convinced that this will be
> > of use to the whole cocoon community: here I go.
> >
> > I write a cocoon Generator. It extends AbstractSAXGenerator and
> > implements CachingPipelineComponent. In order to make good use of the
> > caching mechanism, we use a "ParameterCacheKey", whereby we will use the
> > request parameters to construct the cache key. This makes sense.
> >
> > Consider the methods setup() and constructCacheKey:
> >
> > public void setup(Map<String, Object> parameters) {
> > request = HttpContextHelper.getRequest(parameters);
> > session = request.getSession(true);
> >
> > }
> >
> > and
> >
> > public CacheKey constructCacheKey() {
> > if (request == null) {
> > System.out.println("Sapperment: request is null when
> > constructCacheKey is called...");
> > }
> > Map<String,String> parameters = request.getParameterMap();
> > ParameterCacheKey cacheKey = new ParameterCacheKey(parameters);
> > return cacheKey;
> > }
> >
> >
> > It is observed now that constructCachekey is called before setup is. :-(
> > What to do?
> > Let's find a way and put it as recommended practice, for this will
> > affect virtually any future cocoon app.
> > Ideas?
> >
> > Jos
> >
> >
> >
> > > Reinhard Poetz commented on COCOON3-53:
> > > ---------------------------------------
> > >
> > > The cache key has to contain everything that influences the output
> > > produced by the generator.
> > >
> > > I have no idea why HTML serialization makes a difference, but again, the
> > > logs should give you some hints.
> > >
> > > > Cocoon 3: XMLSerializer caches all
> > > > ----------------------------------
> > > >
> > > > Key: COCOON3-53
> > > > URL: https://issues.apache.org/jira/browse/COCOON3-53
> > > > Project: Cocoon 3
> > > > Issue Type: Bug
> > > > Components: cocoon-pipeline
> > > > Reporter: Jos Snellings
> > > >
> > > > After startup, any pipeline/matcher ending in an xml-serializer will
> > > > produce the output of the first request after server startup,
> > > > regardless of the url, let alone parameters.
> > > > So the first xml pipe that is activated produces the expected output.
> > > > All subsequent calls will echo that output, whatever the url or
> > > > parameters.
> > > > It takes a server restart to make a pipeline ending in an xml
> > > > serializer work again.
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
> > For additional commands, e-mail: users-h...@cocoon.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
> For additional commands, e-mail: users-h...@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
