I thought I'd just drop a note on the list to report on how I dealt with this issue.
At first, I started going down the path of building a module that would somehow override this service, and in the end it turned out that I had to make way too many changes to make it happen. Today, I decided, screw it, I'd apply the patch from https://issues.apache.org/jira/browse/TAP5-1778 , and set up a custom build of tapestry that takes care of this. It turns out it's not a big deal at all , e.g. 1. clone tapestry git repo 2. create a branch off the 5.3 branch, apply the patch from the issue 3. change the name of the version to 5.3-enc-patch in build.gradle . Run ./gradlew build -x test 4. declare a dependency on tapestry-core 5.3.7-enc-patch in my project, build and deploy to gae 5. Ta-da, my newly deployed application on GAE now displays the bulgarian and russian templates as it should , no more ???s - http://www.zadachite.com/bg I really think this patch should be a part of tapestry-core : in the normal case, it would have no effect. In a case like GAE when I don't have control of the underlying platform encoding, this gives a very nice tool to deal with that problem. The only interesting alternative (e.g. one that for example Wicket and Gaelyk have taken to deal w/ the GAE perverted default file encoding) is to take in the value of the file encoding from a system property (e.g. -Dfile.encoding ) instead of from a symbol. In that case, if there are other libraries that might not be aware of tapestry-ioc, they could still use the system property to decide what encoding to use , and in GAE, one can pass in system properties in appengine.xml. Hopefully a committer can apply this patch to tapestry-core. If not, maybe this would be useful to the next person who deploys to GAE and beats his head against the wall long enough just to find this posting. Cheers - On Wed, May 22, 2013 at 7:57 AM, Alex Kotchnev <akoch...@gmail.com> wrote: > Alejandro, > unfortunately, adding the XML declaration doesn't help. . > > This obviously wouldn't be an issue if a) I was running my own JVM, > which in most situations where one hosts an application is the case > (unfortunately, not the case in PAAS like GAE) or b) Tapestry didn't use > the default platform character set. > > Looking at the patch attached to TAP5-1778, I'm not entirely sure if I > can just override a specific service, as the patch appears to touch a whole > bunch of classes, which probably means that if I can override this class, > I'll probably have a copy a whole bunch of T5 source code to do that. The > alternative seems to be to just apply the patch to tapestry-core and deploy > my own build. > > The strange part is that this used to work - when I originally deployed > this application to GAE a couple of years ago, the localized templates > rendered just fine. I remember reading that GAE did change linux distro > underneath their infrastructure (maybe some version of Debian); however, > changing the default character set to US-ASCII hardly makes sense for a > platform provider. There is an existing GAE issue to which I added some > comments - https://code.google.com/p/googleappengine/issues/detail?id=2219 - > feel free to add your own :-) > > Cheers - > > > On Wed, May 22, 2013 at 5:23 AM, Alejandro Scandroli < > alejandroscandr...@gmail.com> wrote: > >> Josh Canfield 've asked a very good question in TAP5-1778. >> does Tapestry respect the XML declaration for changing charset? >> >> Have you tried adding an xml header to your templates?, like: >> <?xml version="1.0" encoding="UTF-8" ?> >> >> >> Alejandro. >> >> On Wed, May 22, 2013 at 9:49 AM, Lance Java <lance.j...@googlemail.com> >> wrote: >> > I think you've hit the nail on the head and that this relates to >> TAP5-1778. >> > >> > As a work around, can you put your special chars in a language specific >> > properties file? By default, prop files are treated as UTF-8. You can >> also >> > override the PropertiesFileParser if you need. >> > >> > Another option is to override the TemplateParser service to use UTF-8. >> See >> > the patch attached to the issue. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> >
