For finding the interesting part quicker, I double quote you:
> Giacomo Pati wrote:
> Yes, too late. IIRC you cannot set any headers when the
> OutputStream was been
> written to.
I think this could be true, so does this mean that the following
is not working?
>>
this.reader.setOutputStream(outputStream);
int length = this.reader.generate();
if (length != 0) {
environment.setContentLength(length);
}
<<
Carsten
> Giacomo Pati wrote:
>
> Quoting Carsten Ziegeler <[EMAIL PROTECTED]>:
>
> > > Giacomo Pati wrote:
> > >
> > > Quoting Carsten Ziegeler <[EMAIL PROTECTED]>:
> > >
> > > > > Giacomo Pati wrote:
> > > > >
> > > > > On Thu, 5 Jul 2001, Carsten Ziegeler wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am currently thinking since some weeks of the following
> > > > enhancement:
> > > > > >
> > > > > > Creating an intermediate output stream for the response and not
> > > > directly
> > > > > > writing to the output stream of the servlet engine (or the
> > > > environment).
> > > > > >
> > > > > > This would solve the following problems:
> > > > > > 1. The output stream can be reset at any time, making
> > > > > redirections possible
> > > > > > at every stage (although I personally don't like this, but
> > > > > there seems
> > > > > > to be a great demand for it)
> > > > > > 2. When the error pipeline is called due to any exception etc,
> > > > > the output
> > > > > > stream should be reset as a new error generator starts
> > producing
> > > > new
> > > > > > output. If accidentally something was already written to the
> > > > output
> > > > > > stream, you get a confusing response.
> > > > > > 3. The special cocoon urls can currently not be used everywhere,
> > > > e.g.
> > > > > > inside a map:redirect-to statement. We could solve this by
> > > > resetting
> > > > > > the intermediate output stream and start on the server a new
> > > > > > generation process without returning to the client.
> > > > > > 4. The content length of each response can be determined. This
> > seems
> > > > > > to be important for the pdf generation (see the corresponding
> > > > thread
> > > > > > on the user list).
> > > > > >
> > > > > > The only disadvante I see currently is some loss of performance.
> > > > > >
> > > > > > Comments? Critics? Suggestions? Wishes?
> > > > >
> > > > > The loss of performance is critical IMHO. One possible solution
> > might
> > > > be
> > > > > to augment the serializer element with an attribute interpretedby
> > the
> > > > > sitemap engine (lets call it set-conten-length="true|false"). As
> > the
> > > > > sitemap engine is the one that gives the OutputStream to the
> > > > serializer
> > > > > an HoldingOutputStream could be craeted by the sitemap engine and
> > > > given
> > > > > the objectModel to set the content length prior to really write
> > the
> > > > > collected output to the real OutputStream. Hnestly, I don't know
> > if
> > > > this
> > > > > approach fits into the caching system.
> > > > >
> > > > > This way you have the performance loss only on serializer with the
> > > > > attribute mentioned above.
> > > > >
> > > > Ok, I am not sure if an intermediate output stream is really such a
> > hugh
> > > > performance loss, but it might be.
> > > > So, I listed 4 points above. We could fix them in the following
> > ways:
> > > > 1. Can be neglected as it is not necessary to make a redirect at any
> > > > time.
> > > > And I think it is bad style anyway. So, put it simple: solved.
> > > >
> > > > 2. I see to working solution for the error pipeline right now.
> > > >
> > > > 3. Using any urls in redirects. We could either forbid this or we
> > could
> > > > make some changes to the engine which would result in performing
> > the
> > > > redirect directly on the server. As at the stage of an redirect
> > > > nothing
> > > > is written to the output stream the engine could simply call
> > itself
> > > > with the new url (actually, this sounds easier as it is, but I
> > think
> > > > it should work.)
> > >
> > > This has to be done with great care. Think about sessions when
> > > doing redirects
> > > that were not originated at the client. You might loose the session.
> > >
> > I think if we simply use the same mechanism as for the cocoon urls this
> > should
> > work.
> >
> > > >
> > > > 4. As the contentLength is only required for the pdf generation I
> > think
> > > > we should go with a Giacomo's proposal with a slight
> > modification.
> > > > I don't like the idea of configuring the behaviour of the
> > serializer
> > > > myself. It is great to have the possibility but it should work
> > > > without any handwork in the sitemap.
> > > > Adding a getContentLength() to the serializer interface and
> > changing
> > > > the behaviour of the fop serializer that it returns the correct
> > > > content length. All other serializers simply return -1 for
> > indicating
> > > > that they don't now the length.
> > > > If it is really required we could at later the configuration of
> > the
> > > > serializers.
> > >
> > > You are absolutely right. Putting in new configuration possibilities
> > mixes
> > > concerns again. But the contract calling getContentLength() is
> > > somehow difficult
> > > as it makes only sense to call it after the pipeline has been
> > > executed. And also
> > > the responsability to cache the output is put down into the
> > > Serializer than. And
> > > how can a Serializer determine if it should use a
> > > HoldingOutputStream instead of
> > > the passed OutputStream if this decision is bound to the call at
> > > getContentLength() (Chicken/Egg problem)?
> > >
> > Hm, this is more difficult than I thought of. Ok, looking at the readers
> > they are implemented in a similar way: the generate() method is invoked
> > which generates the content and it returns the real content length
> > or -1. The stream pipeline and the caching system are taking care of
> > this.
> >
> > With the serializer it could be the same: The serializer itself knows
> > how to handle the output: it knows if he should count the bytes
> > or not. After the processing is finished the stream pipeline asks the
> > serializer for the content length and sets it accordingly. Or might
> > this be too late?
>
> Yes, too late. IIRC you cannot set any headers when the
> OutputStream was been
> written to.
>
> > I thought of (and forgot to mention) a
> > CountingOutputStream
> > which could be used by the serializer. This output stream counts only
> > the
> > passed in bytes and forwards all events to the real output stream.
>
> Sure, for convenience.
>
> Giacomo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
