To muddy the waters a little further! If for some reason (e.g. you are
writing a JSR168 portlet) you cannot use a servlet filters to force
UTF-8 encoding, you can alternatively use a ServletRequestListener.
HTH
Mark
Adam Gordon wrote:
So, for posterity, we finally got this working. After several days of
playing around with a sandbox Struts application that worked, but our
webapp that didn't, we finally realized that the ORDER of the filters
matters (duh...). We put the character encoding filter first in our
chain and it fixed everything.
The problem was it was initially #3 in the chain and in filter #2 I
was reading parameters off the request to look for specific parameters
to mitigate another bug we'd found in production and apparently,
whether by design or otherwise, once you read parameters off the
request setting the character encoding afterwards appears to have no
effect. As mentioned above, moving the character encoding filter to
#1 in the chain fixed it.
Adam Gordon wrote:
I didn't know that page existed though it's essentially what I wound
up doing. My only concern now is that it affects our entire webapp
and while QA was going to do a full regression anyway, I'm wondering
what potential problems are now lurking in the deep, dark corners of
our web forms...
Thanks for the link.
--adam
Ted Husted wrote:
On Nov 28, 2007 10:53 AM, Adam Gordon <[EMAIL PROTECTED]>
wrote:
What about the use of a filter to set the character encoding? Is this
the only way to go for Struts?
I'd say so. It might be possible to add something to the
ActionServlet, but the solution wouldn't be any less "heavy handed"
than using a filter. This sort of thing is why filters were invented
:)
There's a page on the Tomcat wiki that talks about setting up a UTF
filter, if you haven't seen it.
* http://wiki.apache.org/tomcat/Tomcat/UTF-8
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
