CODEWITHSUNDEEP
character-encodingrichfacesjboss7.x
Markus
Markus

Reputation: 89

Encoding of POST requests in JSF 2 on JBoss 7

I have a problem with values POSTed via h:commandbutton, when I enter special characters (ö, ä. ñ, ..). When the value is submitted via an ajax request (e.g. a change listener on the value, or a4j:commandbutton) everything works find. However when the value is submitted via h:commandbutton, the value received gets garbled.

I've tried to set everything according to the article written by BalusC.

I've set the URI enconding in JBoss' standalone.xml:

<property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
<property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>

Added a filter that sets the character encoding of the request. However this does not change anything, the parameters are messed up there if I read get the param map (either before or after setting the encoding).

Is there anything else I've missed?

I've tried with JBoss 7.1.0 and 7.1.1 and richfaces 4.1.0.

Edit:

Even if ExternalContext#getRequestCharacterEncoding() returns UTF-8 in the beans action method (as asked in the comment), it looks like the filter is the problem. When the form is submitted via h:commandButton, request.getCharacterEncoding() returns null at the beginning of the doFilter() method of the UTF filter I added. But request.parametersParsed is already true.

When the value is submitted via ajax request.getCharacterEncoding() is already UTF-8.

So it looks like the encoding is set differently and some other filter already parses the parameters. The only other filter in the request.context.filterConfigs is org.jboss.weld.servlet.ConversationPropagationFilter. Plus Picketlink probably already has read the parameters at this point.

Edit 2: As discussed in this thread in the PL forum this seems to be a bug in Picketlink. Also check the related PL issue.

Upvotes: 0

Views: 2025

Answers (1)

BalusC
BalusC

Reputation: 1108782

Everything looks fine so far.

This construct will only fail if something else has already accessed (and thus implicitly parsed) the request body before your character encoding filter has set the request body character encoding. It's then too late to set the character encoding for parsing of the request body.

Based on the comments, PicketLink seems to be the culprit here. You need to tell it to use UTF-8, or if that's not possible, report a bug/issue report at their development team. This all is at least beyond control of JSF and hence not a JSF related problem.

Upvotes: 1

Related Questions