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: >>> org.springframework.context.support.ClassPathXmlApplicationContext >>> 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: https://issues.apache.org/jira/browse/COCOON3-47 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 http://en.wikipedia.org/wiki/HTTP_ETag). 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 above. WDYT? -- Reinhard Pötz Managing Director, {Indoqa} GmbH http://www.indoqa.com/en/people/reinhard.poetz/ Member of the Apache Software Foundation Apache Cocoon Committer, PMC member [email protected] ________________________________________________________________________
