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, 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.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
