cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <>
Subject Re: cocoon3 sitemap call
Date Wed, 09 Dec 2009 11:25:00 GMT
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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message