cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: [Corona] PIpeline API
Date Mon, 14 Jul 2008 09:37:13 GMT
Carsten Ziegeler wrote:
> Reinhard Pötz wrote:
>> I agree with you that the package structure should be cleaned up. It's 
>> also a good idea to create a 'corona-pipeline-sax' module that 
>> contains the SAX based components. I'm not so sure if we should really 
>> move the pipeline implementations into their own modules. This seems 
>> to be too much modularization for my taste. (The corona-pipeline.jar, 
>> that currently contains the SAX components, is about 70kb only.)
> Yes, I'm not concerned about the jar size itself, I'm concerned about 
> dependencies. The ideal solution would be to have an api jar which has 
> no other dependencies, perhaps one to a logging framework if we provide 
> utility or abstract classes.

currently corona-pipeline (pipeline API, pipeline impls, SAX components) 
only has a dependency on commons-logging. Is this good enough for your 

>>> b) Actions should not be part of the pipeline api
>>> I think we discussed this some time ago :) Removing actions from the 
>>> pipeline stuff does not really hurt - they are invoked before the 
>>> pipeline, so it shouldn't be too hard to build custom code which 
>>> collects actions, assembles the pipeline, invokes the actions and 
>>> then the pipeline.
>> no objection ;-)
>>> c) Pre and post processing
>>> As the pipeline interfaces are not tied to sax or any other model 
>>> (which is ok), there is no explicit notion of indicating that the 
>>> processing starts or is finished - the latter is especially 
>>> interesting for cleanup. So I think we should add these two lifecycle 
>>> methods to the pipeline component interface.
>> I don't see any problem either. Being curious, what are your use cases?
> I've some pipeline components that open/close resources, like a JCR 
> session for instance. If the contract includes that the pre and post 
> processing methods are always called, the post processing method acts 
> like kind of a disposal method where I can close my session.
> I've other - in this sense rather obscure - use cases where the pipeline 
> components need to pass information back to the caller before the 
> processing starts. So the caller calls the pre processing method where 
> the pipeline component adds something to the map, the caller can pick it 
> up and then start the processing based in this information.


>>> d) Splitting setup and execute
>>> I would like to split the Pipeline#execute method into two, one for 
>>> initialisation and one (without arguments) for executing.
>> I was thinking about this myself because we need this separation also 
>> to optimize conditional GET operations when the servlet URLs are 
>> involved.
> Great :)
> So how do we proceed? Do you mind if I start with the minor changes?

of course not :-)

Corona comes with integration tests that you can run by invoking

mvn clean install -P it -Dhtmlunit.base-url=http://localhost:8888

from the root directory. Please make sure that they run through after 
your refactorings. Many thanks in advance!

Reinhard Pötz                           Managing Director, {Indoqa} GmbH

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

View raw message