cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)" <>
Subject RE: Bug 4124 StreamGenerator does not preserve XML encoding PI
Date Mon, 15 Oct 2001 15:16:59 GMT

Carsten wrote:

>> Carsten,
>> 1. I did fix the problem reported as Bug 4124. Is it enough to send
>> the cvs diff or you want the full file attached? Please let me know.
>> The fix is in I like as well to update
>> (util).
>A diff is fine. Just send in two diffs one for each file.

>> 2. Speaking about StreamGenerator, few days ago somebody complained
>> about StreamGenerator not processing data from input stream.
>> I noticed that it is a difference between my original submitted file and
>the current version.
>Yes, I patched the StreamGenerator days ago, but after the release
>of 2.0rc1a, because the type cast of the Request object to HttpRequest
>does not work, if you use the StreamGenerator inside an included pipeline.
>For example:
<map:match pattern="test">
  <map:generate src="cocoon://include"/>
  <map:serialize type="xml"/>
<map:match pattern="include">
  <map:generate type="stream"/>
  <map:serialize type="xml"/>

>In this case, the Request object of the objectModel in the included
>pipeline is not an HttpRequest object!

Then what is it? It is implementing Request, it is able to answer what is
ContentType, it is able to answer what is ContentLength but it does not know
anything about inputStream. Something is not right here.

Maybe it is time to review the relationship between Request, HttpRequest and
HttpServletRequest. You probably remember the discussion we had about
inconsistencies between cocoon abstractions for HttpServletRequest. You said
then that there are the reasons to abstract from original
HttpServletRequest. That fine, but if HttpServletRequest is wrapped it
should be done without "holes" and it should behave like real
The inconsistencies are in the definitions Request interface exposes, some
HttpServletRequest interface methods are not part of Request but they are
implemented by HttpRequest. The example is getInputStream().

In this specific case I feel that with proper Request interface definition
we should be able always work with Request or HttpRequest and it should be
the responsibility of included pipeline processing or any other lower level
processing to initialize correctly all wrapper instance fields. If possible
of course!

I like really to explore first more global picture to make sure that we do
not patch the symptoms instead of curing the real problem. I like to invite
you to review the fundamentals and to make sure it is really nothing that
can be done to make everything in this area more precise and clear.

If we will use in StreamGenerator explicit HttpServletRequest - we somehow
prove that the concept of wrapper is not so useful or not so universal.


To unsubscribe, e-mail:
For additional commands, email:

View raw message