Carsten,
I still hope that we can cure the real problem but on the other hand I do
not want to wait longer with my patches.
For now I am sending a patch where HttpServletRequest is used in
StreamGenerator, but really it does not satisfy me!
Now about character encoding. Servlet 2.3 spec have new methods to help
manage character encoding. HttpServletRequest has get/setCharacterEncoding
methods. The spec is not very clear in which cases container should
initialize the value for character encoding.
Because of the fact that we can deal with container implementing 2.2 spec or
the container will choose to not initialize the value for character
encoding, we need to compensate for that.
Stream generator is checking if the Content-Type contains charset
specification, then is asking container "getCharacterEncoding()". If the
container answer is "null" or the container is not implementing this method
(exception), StreamGenerator parses the Content-Type header value to obtain
the charset encoding.
It is a common mistake to send the Content-Type header like this:
Content-Type:text/xml; charset="UTF-8" the correct header value is
Content-Type:text/xml; charset=UTF-8 (For example the
org.apache.cocoon.components.language.markup.xsp.SOAPHelper.java has that
mistake). Some containers compensate for this mistake, some are not. Because
of this discrepancy StreamGenerator is compensating this mistake.
As a next step the encoding is passed to the InputSource and parser can use
this info to correctly read the data.
In general in order to fully support encoding the Serializer should set the
Content-Type for the response to correspond to this for Request.
It looks that StreamGenerator's getCharacterEncoding method may be needed by
Serializer as well. ( To cover the cases where container is not implementing
get/setCharacterEncoding method, or to correct the common mistakes).
Maybe this method should be moved to more"global" place to be accessible for
more components. Let me know what do you think.
I understand that it is in our interest to continue the discussion/cleaning
Request/HttpRequest/HttpServletRequest relationship.
Attached please find the diff files for StreamGenerator and PostInputStream.
Regards,
Kinga
----- Original Message -----
From: "Carsten Ziegeler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 16, 2001 4:39 AM
Subject: AW: Bug 4124 StreamGenerator does not preserve XML encoding PI
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:[EMAIL PROTECTED]]
> Gesendet: Montag, 15. Oktober 2001 17:17
> An: '[EMAIL PROTECTED]'
> 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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
StreamGenerator.java.diff
PostInputStream.java.diff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
