I noticed this once, but with weld 1.1.
Something is screwing up the servlet request's characterEncoding. This may be caused by weld's ConversationFilter.
You can fix it by adding your own filter that sets the characterEncoding to UTF-8 or whatever you're using.
Of course, the filter needs to be first in line, as you must call servletRequest.setCharacterEncoding("UTF-8") before anyone invokes servletRequest.getParameter().
Thank you very much for your answer. But unfortunately the parameters are already parsed when I hit the first Filter.
It seems that the problem is a ServletListener implemented by Weld. here is the call stack:
Request.parseParameters:2853 Request.getParameter:1131 ConversationContextActivator.getConversationId:115 ConversationContextActivator.activateConversationContext:82 HttpContextLifecycle.requestInitialized:132 WeldListener.requestInitialized:107 ForwardingServletListener.requestInitialized:42 StandardContext.fireRequestInitEvent:5974 StandardContextValve.invoke:181 AuthenticatorBase.invoke:472 StandardHostValve.invoke:151 ErrorReportValve.invoke:100 AccessLogValve.invoke:929 StandardEngineValve.invoke:118 CoyoteAdapter.service:405 Http11Processor.process:269 AbstractProtocol$AbstractConnectionHandler.process:515 JIoEndpoint$SocketProcessor.run:302 ThreadPoolExecutor$Worker.runTask:895 ThreadPoolExecutor$Worker.run:918 Thread.run:662
This is called before the first Filter is invoked. In this case it seems that I have no chance to set the encoding before the first Parameter is read.
OK, you also need to manually register Weld's ConversationFilter (org.jboss.weld.servlet.ConversationFilter). WeldListener will not parse parameters if the ConversationFillter is registered in web.xml.
I know this is a real pain. I'll see if we can fix this.
Thank you very much. I'll try this the next days. Hope this will get fixed.