cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jos Snellings <Jos.Snelli...@pandora.be>
Subject ParameterCacheKey for a Generator.
Date Tue, 09 Mar 2010 12:58:44 GMT
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-unsubscribe@cocoon.apache.org
> > For additional commands, e-mail: users-help@cocoon.apache.org
> > 
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
> 
> 



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


Mime
View raw message