cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <>
Subject Re: [c3] Pipeline results
Date Tue, 13 Jan 2009 18:24:40 GMT
On Tue, Jan 13, 2009 at 12:00 PM, Carsten Ziegeler <> wrote:
> Grzegorz Kossakowski wrote:
>> Your problem made me to analyze Cocoon3 Pipeline API very carefully and think about
it for a while. What I found rather
>> strange is PipelineComponent interface, see:
>> public interface PipelineComponent {
>>     void setConfiguration(Map<String, ? extends Object> configuration);
>>     void setup(Map<String, Object> parameters);
>>     void finish(Exception exception);
>> }
>> Why I think this interface is strange (and confusing)? Becuase it does not deal with
the most important aspect of
>> PipelineComponent: that it processes something and that it can be combined with other
components. The most important
>> aspect is neither configuration nor setup of a component.
>> I started to think that we will have such problems like the one mentioned in this
thread as long as we don't address
>> issues with PipelineComponent.
>> I've decided to experiment with the code (after analyzing the problem on a paper)
and you can see results here:
>> This code proves only one thing: that I failed to address an issue mentioned above.
What I'm interested in is if others
>> share my concerns about PipelineComponent interface (and Pipeline itself) and if
you also see a relation to problem with
>>  pipeline result?
> I agree that the PipelineComponent interface looks really strange. It's
> absolutely not clear what the difference between setConfiguration and
> setup is - so I think we need better names here.
> The finish method looks also strange as it gets an exception as a
> parameter. The question is if a component should really now what
> exception occured during a pipeline run or if a boolean is sufficient.
> Apart from that I think, the interface is the price we have to pay for
> the flexibility we get.

I guess part of the debate is whether it is worth defining some
additional method, eg:

  CocoonOutput execute( CocoonInput genericInput) throws ?;


  Object execute( Object genericInput) throws ?;

I really can't see that the CocoonOuput and CocoonInput are anything
more than marker interfaces and this of course means that more
standard objects have to be wrapped so I think the  second  version is
preferable.  But that certainly doesn't buy you anything as far as
pipeline contracts are concerned for traditional Java.  However, I do
think that perhaps this opens up some longer term possibilities for
Aspect oriented inspection across the pipeline so maybe it is actually
worth adding?

Peter Hunsberger

View raw message