Carsten Ziegeler wrote:
Joerg Heinicke wrote:
Carsten Ziegeler <cziegeler <at> apache.org> 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.
agreed
--
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]
________________________________________________________________________
