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 Tue, 15 Jul 2008 19:58:44 GMT
Carsten Ziegeler wrote:
> Joerg Heinicke wrote:
>> Carsten Ziegeler <cziegeler <at>> writes:
>>>>> 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.
>> Isn't that a rather specific use case? It feels kinda "wrong" when 
>> lifecycle
>> methods will now "pollute" the pipeline interfaces rather than letting 
>> pipeline
>> components implement lifecycle interfaces. Doesn't Spring show how to 
>> do these
>> kind of things with templates or aspects?
>> And is there actually something like "start" and "end" in a pipeline? 
>> How do you
>> determine that? It's rather easy with SAX since there is 
>> startDocument() and
>> endDocument() but in general?
> Hmm, someone starts the pipeline and at some point of time it ends :) As 
> we have an execute() method on the pipeline, the contract is that if 
> execute returns, the pipeline is finished. Therefore it's easy to call 
> the according methods inside execute() - regardless which model is used 
> between the pipeline components.
> We have the pre-execution method already - thats the setup(Map) method.
> I added now a finish method which is called by the pipeline implementation.
> This keeps me free from any configuration hassels with the various 
> containers. Some want to use spring, some others something different. 
> And perhaps someone doesn't want to use a container at all

that's IMO the main reason for adding the finish() method.

>, just 
> instantiate the objects, run the pipeline and that's it.
> Therefore I really think that these lifecycle methods belong to the api.
> I see no other reliable way of closing resources.


Reinhard Pötz                           Managing Director, {Indoqa} GmbH

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

View raw message