|
Description:
|
Since Weld 2.0 reads request parameters {{cid}} and {{conversationPropagation}} at the start of each request (it does this in a ServletListener), applications lose the ability to call {{request.setCharacterEncoding()}}
.
Setting
, since setting
the character encoding has an effect only until the web container parses the query string (or POST request body).
Applications that do not use CDI have full control over this. It is their responsibility to make sure to call {{setCharacterEncoding()}} and only then read request parameters. But as soon as an application uses CDI/Weld2.0, the only way for an application to set the character encoding is to add a servlet filter that sets it, and also manually add Weld's ConversationFilter (to prevent WeldListener from reading the parameters
before any filter is called
).
Ideally, Weld should not interfere with the application. This means Weld should not read the parameters until after the application has had a chance to set the encoding (actually, until after the application itself has caused the parameters/body to be parsed). This is not achievable, because the application can invoke a conversation scoped bean before it has read any parameters. So, the best we can possibly do is read the {{cid}} parameter only when we need to access the conversation. The application then needs to make sure it has set the encoding before that.
Another option would be for Weld to
do
the parsing itself, but this would only help in situations where the {{cid}} is in the query string, not in the POST request body. If the CDI spec demanded the {{cid}} to always be in the query string, this would be the way to go
.
, but currently the spec uses the term "request parameter" for both {{cid}} and {{conversationPropagation}}
|
