Ryan Lubke wrote:
> Gerald Holl wrote:
>> Ryan Lubke wrote:
>>
>>> I'm guessing it's this snippet in Woodstock's UploadFilter (present in
>>> the most recent set of stacktraces):
>>>
>>> if (!FileUpload.isMultipartContent(req)) {
>>> chain.doFilter(request, response);
>>> return;
>>> }
>>>
>>> If the request isn't multipart/form-data, the UploadFilter invokes the
>>> filter chain.
>>> If it is, then further in the processing setRequestEncoding is called.
>>>
>>
>> I took a look at the woodstock UploadFilter source and the character
>> encoding is set to UTF-8 if request.getCharacterEncoding() returns null.
>> So I don't understand why the characters are broken.
>>
> If the content type can't be determined from the request,
> getContentType() will be null.
> The reason you get this message printed to the log is because the filter
> sets the the character encoding
> and then obtains query parameters (doing this effectively locks the
> encoding for the duration of the request). Later in the request
> processing, the JSF lifecycle will set the character encoding when
> initializing the view and this triggers the warning.
We were using an old woodstock impl. In that impl
request.setCharacterEncoding() was never called, so the form submit
broke some characters.
This bug is solved in the latest woodstock impl.
> I wouldn't characterize anything here as broken per se. This message is
> informational (perhaps it's too verbose).
> That said, I'll look into a modification in the JSF api and see if the
> warning can be eliminated.
In my mind the warning shouldn't be eliminated since it indicates that
there might be a problem with the character encoding.
cheers & thanks for your help,
Gerald