cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: Bug 4124 StreamGenerator does not preserve XML encoding PI
Date Tue, 16 Oct 2001 08:39:26 GMT
Hi Kinga,

I totally agree with you that it is better to "cure the real
problem instead of patching symptoms".

As far as I know there were decisions in the early days of C2
that the whole system should be made "safe", which means
objects should only expose methods() which can be could by
clients.
One example for this is the getOutputStream() method
of the Response object. No object except the serializer
should be able to write to the response.

Now I don't know why the getInputStream() method is not
available to the Request object. Stefano or Giacomo,
can you enlighten us here?

I personally don't like that the HttpServletRequest and
HttpServletResponse objects are available using the hack.
But they are unfortunately required for some components
like the PhpGenerator. But it would be better if we could
remove that hack!

Perhaps we should really take some time, and rethink
of the Request/Response/Session/Context interfaces.
If they expose everything needed or if they expose
too much etc.

So, we need more feedback here.

Regards,
Carsten
> -----Urspr√ľngliche Nachricht-----
> Von: DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)
> [mailto:kinga_dziembowski@hp.com]
> Gesendet: Montag, 15. Oktober 2001 17:17
> An: 'cocoon-dev@xml.apache.org'
> Betreff: RE: Bug 4124 StreamGenerator does not preserve XML encoding PI
>
>
>
> 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 StreamGenerator.java. I like as well to update
> >>PostInputStream.java (util).
> >Great!
> >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>
> <map:match pattern="include">
>   <map:generate type="stream"/>
>   <map:serialize type="xml"/>
> </map:match>
>
> >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
> HttpServletRequest.
>
> 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.
>
> Kinga
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message