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
needs?
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.
thanks
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
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
________________________________________________________________________
