cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject [c3] Conditional GET
Date Wed, 09 Dec 2009 18:38:42 GMT
Steven Dolg wrote:
> Reinhard Pötz schrieb:
>> Thomas Markus wrote:
>>> i missed the aop part
>>> it would be great to move all servlet independent parts outside of
>>> cocoon-servlet (CallStack ...), maybe to cocoon-pipeline
>>> currently i cant use cocoon-servlet as dependency (and dont want).
>>> org.springframework.beans.factory.BeanCreationException: Error creating
>>> bean with name
>>> 'org.apache.cocoon.blockdeployment.BlockContextURLStreamHandlerFactory'
>>> defined in class path resource
>>> [META-INF/cocoon/spring/cocoon-blockdeployment-protocol.xml]:
>>> Initialization of bean failed; nested exception is
>>> java.lang.ClassCastException:
>>> cannot be cast to org.springframework.web.context.WebApplicationContext
>>> i try to run a sitemap inside a junit test without any servlet specific
>>> parts. this works fine without coocon-servlet. after copying CallFrame,
>>> CallStack, MimeTypeCollector and spring config (ugly i know) mimetype
>>> is ok.
>> I refactored all *Collector aspects and merged them into
>> o.a.c.servlet.collector.ResponseHeaderCollector. This collector uses
>> data store that implements o.a.c.servlet.collector.CollectorDataStore
>> and provided two implementations: one uses a thread local the other the
>> CallStack of the ServletService framework.
> That sounds good.
>> This means that the ResponseHeaderCollector doesn't have a dependency on
>> the SSF or the Servlet API any longer.
> That sounds even better.
>> The last step would be moving it into cocoon-sitemap but I have to find
>> a way to ensure that there is no other class in cocoon-sitemap that
>> depends on it. Alternatively I could create an own module but it seems
>> odd to me doing this for a single class.
> Sitemap should be the right place for this.
> Pipeline is definitely too low, iow. the infrastructure is missing to
> ensure that those things are actually happening.
> The purpose of the pipeline module is to allow direct programmatic
> creation and execution of Cocoon pipelines - wherever you want and no
> matter which other frameworks you might use.
> (Just like you would use commons-lang or commons-logging).
> The sitemap is the first layer that actually creates some kind of
> predictable environment for the Cocoon pipelines and thus is the first
> layer where we can actually rely on assumptions like
> having AOP or access to certain information.

I'm still not sure where the ResponseHeaderCollector should go to but I
agree with you that cocoon-pipeline is too low.

But let me broaden the picture: Based on our work from about two weeks
ago, I created another aspect which implements the support for
conditional GET requests and also takes care that a pipeline isn't
executed unless it is really necessary. I was also able to fix all
failing test cases. I created an issue that contains a patch:

Additionally there is also another feature that I would like to add: The
current patch only takes care of 'If-Modified-Since' requests. I also
want to support 'If-None-Match' requests that are based on the 'ETag'
response header. (see

Using ETag has the advantage that we could support conditional GET
requests also in the case where we can't use a timestamp based approach
 (e.g. when using o.a.c.pipeline.caching.ParameterCacheKey) or to
provide conditional GET support in REST controllers.

As an ETag value we could use the hash code of a pipeline's cache key.

Finally back to the initial question: Maybe it's easier to decide where
things should go to after the conditional GET support works as outlined


Reinhard Pötz                           Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member        

View raw message