I'm not sure if this is severe or not, but I think there's a gap in the
implicit assumptions underlying WicketFilter.checkCharacterEncoding():
It seems the author's intention was to guarantee a postcondition of
servletRequest.getCharacterEncoding() != null,
but this postcondition does not hold in all cases.
I ran into this issue after upgrading my Glassfish app server from 3.0.1 to
3.1-b12, containing a newer release of Weld which causes the problem to appear.
After this upgrade, my log was full of warnings of the following type:
WARN o.apache.catalina.connector.Request - PWC4011: Unable to set request
character encoding to UTF-8 from context /xxx, because request parameters have
already been read, or ServletRequest.getReader() has already been called
Setting a couple of breakpoints revealed that Weld registers a
ServletRequestListener and calls request.getParameter() in that listener. By
specification, this listener gets called before all servlet filters, including
WicketFilter, and again by specification, the invocation of
servlet.request.setCharacterEncoding() from WicketFilter has no effect, since a
request parameter has already been read by the WeldListener.
So it there are other parts of Wicket relying on the request character encoding
to be non-null, then this looks like a bug to me. Otherwise, if Wicket handles
a null character encoding gracefully, then checkCharacterEncoding() is
redundant, because it cannot be guaranteed to have any effect.
Regards,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
