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(), 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