cocoon-dev mailing list archives

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

thanks for your patch, it's applied. Please cross-check.

Let's see how (if?) the discussion about the refacturing
goes on.

Carsten

> -----Original Message-----
> From: kingadziembowska [mailto:kingadziembowska@msn.com]
> Sent: Monday, October 22, 2001 7:09 AM
> To: cziegeler@sundn.de
> Cc: cocoon-dev@xml.apache.org
> Subject: Re: Bug 4124 StreamGenerator does not preserve XML encoding PI
>
>
> 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" <cziegeler@sundn.de>
> To: <cocoon-dev@xml.apache.org>
> 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: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
>
>
>


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


Mime
View raw message