Hi Carsten, Thanks for application of the patch. Looks OK.
Kinga ----- Original Message ----- From: "Carsten Ziegeler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 23, 2001 8:14 AM Subject: RE: Bug 4124 StreamGenerator does not preserve XML encoding PI >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:[EMAIL PROTECTED]] > Sent: Monday, October 22, 2001 7:09 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > 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" <[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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
