OK, after a head-spinning detour through the bowels of Tapestry, I've
found the problem.
Line 213 of AjaxDirectServiceImpl gets the content type from the
responseBuilder. DojoResponseBuilder has it hard-coded as "text/xml".
That content type then gets passed to webResponse.getPrintWriter(),
which passes the type on unmodified to ServletResponse.setContentType().
The javadoc for ServletResponse.getCharacterEncoding() informs us
that "If no charset has been assigned, it is implicitly set to
ISO-8859-1" -- but there is no ServletResponse.setCharacterEncoding()
method. Instead, both content type and encoding are set through
ServletResponse.setContentType().
So, by passing webResponse.getPrintWriter() a content type without a
charset, Tacos is forcing the response charset to be ISO-8859-1
regardless of Tapestry's settings. That is arguably a bug in
Tapestry, not Tacos, but internally Tapestry is very careful to
append the content type when calling getPrintWriter(), and Tacos
should do the same.
The quick fix is to apply the global default output encoding:
RCS file: /cvsroot/tacos/tacos4/src/java/net/sf/tacos/ajax/impl/
AjaxDirectServiceImpl.java,v
retrieving revision 1.25
diff -r1.25 AjaxDirectServiceImpl.java
213c213,214
< ContentType ct = new ContentType
(responseBuilder.getContentType());
---
> ContentType ct = new ContentType
(responseBuilder.getContentType()
> + ";charset=" + cycle.getInfrastructure
().getOutputEncoding());
This fixes my problem.
It might be good to first get hold of the page, and check
page.getResponseContentType().getParameter(ENCODING_KEY) before using
the default, in the unlikely event that somebody has specified their
encodings on a page-by-page basis. But I'm sure this patch will cover
it for most people.
Do you need me to submit a bug report, or is this email sufficient?
Cheers,
Paul
On Dec 18, 2005, at 11:09 PM, Leonardo Quijano Vincenzi wrote:
Ok, I guess we are going to check this one later (maybe Felix can
help over there in China ;)), but, by the way, did you file the bug
report?
Just that we don't forget about it.
I have a killer headache... going to bed ;).
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Paul Cantrell wrote:
I had the template-encoding setting already, and added the output-
encoding setting to my tapestry.application -- but it didn't help.
Is there somewhere these need to be set for Tacos, too...?
Passing -Dorg.apache.tapestry.607-patch=true on the Tomcat command
line, apparently the workaround for TAPESTRY-607, does not help
either.
Leonardo: You aren't encountering the bug because it does not
affect many extended Latin characters (presumably because they're
supported by iso-8859-1), including the ones used in Spanish
(áéíóúñ). Try dropping this in your page template, and watch
it break when it's passed back via Ajax:
—π™… ♣♬☂參
Cheers,
Paul
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Tacos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tacos-devel
_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Tacos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tacos-devel
