Anyone on this?... seems like bug reports are being overlooked lately...
Thanks, -- Ing. Leonardo Quijano Vincenzi Director Técnico DTQ Software Leonardo Quijano Vincenzi (JIRA) escribió:
[ http://issues.apache.org/jira/browse/TAPESTRY-607?page=comments#action_12330535 ]Leonardo Quijano Vincenzi commented on TAPESTRY-607: ---------------------------------------------------- This is what I think it's happening. I'm using Apache Tomcat 5.5.12alpha, Tapestry 4.0-beta-8. I'm having problems using the UTF-8 and error pages. Then: 1) On the first page rendering, the content type for the PrintWriter is setup appropiately in ServletWebResponse.getPrintWriter(): public PrintWriter getPrintWriter(ContentType contentType) throws IOException { Defense.notNull(contentType, "contentType"); if (_needsReset) reset(); _needsReset = true; _servletResponse.setContentType(contentType.toString()); try { return _servletResponse.getWriter(); } catch (IOException ex) { throw new ApplicationRuntimeException(WebMessages.writerOpenError(contentType, ex), null, ex); } } 2) After we already have the writer, the application throws some exception and the rendering is forwarded to another page (same HttpServletResponse). Then we come again to page rendering (and to call getWriter() again). 3) The first time reset() is called, the content-type is reset. Then _servletResponse.setContentType() is called and the encoding is changed to UTF-8 as it should. The second time reset() is called, _servletResponse.setContentType() won't work (it won't change the encoding), because we already have a writer selected: (from Tomcat's org.apache.catalina.connector.Response): /** * Set the content type for this Response. * * @param type The new content type */ public void setContentType(String type) { if (isCommitted()) return; // Ignore any call from an included servlet if (included) return; // Ignore charset if getWriter() has already been called if (usingWriter) { if (type != null) { int index = type.indexOf(";"); if (index != -1) { type = type.substring(0, index); } } } It strips out the encoding from the content-type. That leaves us with a reset() response writer, and encoding ISO8859-1. That causes the "????" when rendering. I guess the fix would be to avoid resetting the response a second time in the same request?? Comments?"UTF-8" page coming to "?????" After continuous cycle.actived page ------------------------------------------------------------------ Key: TAPESTRY-607 URL: http://issues.apache.org/jira/browse/TAPESTRY-607 Project: Tapestry Type: Bug Components: Framework Versions: 4.0 Environment: jdk1.4,tapestry4-beta5 Reporter: JoneAfter upgrading my project from beta4 to beta5,the utf-8 encoded Chinses,Japanese characters comes into "????".In fact ,the problem occurs in continuous actived pages.For example,In page1,in direct lisener mehtod invoke "cycle.active('page2')",then in page2,in pageBeginRender() invoke "cycle.active(page3)",now in rendered page3,all the "utf-8" character comes in to "????".
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
