On 15-01-2009 at 12:21, Jan Moravec wrote: > > Anyway, I still feel there should really be two _separate_ methods for > obtaining the request and response character encoding in the LocalePicker > API - the rationale being that IMO nothing mandates that request charset > encoding always matches the response charset encoding (I admit it is very > offen the case, but not always as we see in this common "download some > generic octet stream data" case).
Actually, the Resolution determines the response content type (and thus character encoding). And even then, there are multiple scenario's: - ErrorResolution & RedirectResolution no content, and thus no content type / character encoding - ForwardResolution the URI being forwarded to determines what happend next; for example, when forwarding to a JSP page, the JSP page determines the content type. - StreamingResolution Your case; you specify the character encoding as it applies, but appearently a bug in Tomcat 6 botches it. ... So as you can see, the LocalePicker is actually not used. In fact, it's only used to set the character encoding on the request, to read the parameter. Oscar -- ,-_ Oscar Westra van holthe - Kind http://www.xs4all.nl/~kindop/ /() ) (__ ( Progress is made by lazy men looking for easier ways to do things. =/ () -- Robert Heinlein ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
