Reinhard Pötz wrote:
> But still there is one limitation that has bugged me several times: The
> result of all pipelines is that they write something into an output stream.
> That's the original use case for pipelines used in servlet environments
> and probably true in many cases but not in all.
> One use case that I have is that I want to get the SAX events written
> into a SAX buffer or some might want to make the pipeline write into
> some content handler directly that they pass to it.
> 
> Another use case is when you want to use pipelines to create business
> objects as their result. (I guess Simone can give more details here.)
> 
> In all these cases you don't need an output stream.
Yes, I had recently the same idea when I wanted to write the output to a
writer instead of an output stream (now this is easy to do with a
wrapper but still it could be easier).

> 
> 
>                                   - o -
> 
> 
> In order to make the pipeline result pluggable, I propose following
> changes:
> 
> I would like to introduce a generic Result interface which is the
> transport vehicle for the actual result:
Ah, here we have the new interface :)

> 
> public interface Result<T> {
> 
>     void setResultObject(T o);
> 
>     T getResultObject();
> }
> 
> And here is a possible implementation of a Result that carries
> an output stream:
> 
> public class OutputStreamResult implements Result<OutputStream> {
> 
>     private OutputStream os;
> 
>     public OutputStream getResultObject() {
>         return os;
>     }
> 
>     public void setResultObject(OutputStream o) {
>         this.os = o;
>     }
> 
>     public String getContentType() {
>         ...
>     }
> 
>     public long getLastModified() {
>         ...
>     }
> }
> 
> The pipeline interface would have to change accordingly:
> 
> public interface Pipeline<T> {
> 
>     void addComponent(PipelineComponent pipelineComponent);
> 
>     void addComponent(Finisher<T> finisher);
> 
>     void execute() throws Exception;
> 
>     void setup(Result<T> result);
> 
>     void setup(Result<T> result, Map<String, Object> parameters);
> 
>     void setConfiguration(Map<String, ? extends Object> parameters);
> }
> 
> As you can see, the methods getContentType() and getLastModified() were
> moved to the result object where they fit much better IMO because both
> are specific for our output stream use case.
> 
> And thanks to generics, the compiler makes sure that only a Finisher (=
> serializer) can be added to the pipeline if it supports a particular
> result type:
> 
> public interface Finisher<T> extends PipelineComponent {
> 
>     void setResult(Result<T> result);
> }
> 
> 
Hmm, not sure :) How does this it actually work - what does a serializer
need to do?
There is a slight overlap between the serializer and the result - for
example if you want to get java objects out of the pipeline, you might
want to use a special serializer. So maybe we can merge the two?

Carsten


-- 
Carsten Ziegeler
cziegeler@apache.org