Hi Ed,
Ed Burns wrote:
> Hi Jan,
>
> The change in the contract of the method mentioned in the subject of
> this message seems to have broken at least two things:
>
> 1. deployment of a web module using the admingui in glassfish
>
> 2. jsf
OK, this is bad.
> Now, I understand the rationale for doing this, and it makes sense to
> me, so don't consider rolling it back just yet.
Good. The stricter handling of ServletRequest.setCharacterEncoding() is
exposing deficiencies in existing webapps, which have assumed that a
charset was successfully set, where in reality it was being ignored.
> However, please be
> advised that the above two places are probably not the only places that
> will hit this.
>
> Jan, can you see what we can do about this?
From the stack trace you sent, it looks like
com.sun.enterprise.tools.admingui.servlet.UploadServlet.doPost
is parsing req params from the POST body and then request dispatching
to
com.sun.enterprise.tools.admingui.AdminGUIServlet
which then calls setCharacterEncoding(), which causes the ISE,
because some req params have already been parsed.
What we could do is have setCharacterEncoding() throw the ISE only
if (getReader() has been called || req params have been read)
AND the newly supplied encoding is different from the encoding
that was used to parse the body.
I can propose this to the EG. What do you think?
Jan
> I'm trying to find a workaround for the JSF case. For the deployment
> case, autodeploy seems to work still.
>
> Ed
>