Can't deploy webapp using adminGUI with 20050618 nightly about glassfish

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/23
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @yaminikb
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented
jluehe said:
From the stack trace, 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 by UploadServlet.

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 has been used to parse the body.

I can propose this to the EG. What do you think?

[glassfishrobot]

@glassfishrobot Commented
@edburns said:
Of course, in the case of faces, we could modify the RI to catch the ISE and
ignore it, but 1: that's a performance killer 2. the code that does it is
pluggable, so we can't change it and expect those that override the ViewHandler
will do the same.

Ed

[glassfishrobot]

@glassfishrobot Commented
@edburns said:
I don't think that'll work. Let's say a webapp wants to use UTF-8 for
everything. So, they use JSP directives to set a content type

Content-Type: text/html; charset=UTF-8

Now, when the browser submits the form, it'll convey any character
encoding that it is configured to, regardless which encoding was used in
the page from which the submit is originating. In JSF, we need to
ensure that UTF-8 is set as the character encoding, so in this case, the
encoding will be different and we'll still get the ISE.

Ed

[glassfishrobot]

@glassfishrobot Commented
@edburns said:
This would work for me:

Allow calling getParameterNames().

Here's a rationale. Since JSF 1.1, we have been setting the request character
encoding on postback for the reasons previously described in this issue. In JSF
1.2, we have a new method that requires us to inspect the parameter set for the
presence of a specific parameter and we take action accordingly, before the
character encoding is set. I think it's safe to allow calling
getParameterNames() because they are probably ASCII. It's the values that are
more likely non-ascii.

[glassfishrobot]

@glassfishrobot Commented
@edburns said:
Actually, Ryan pointed out to me that what I suggest won't work.

He suggests, and I endorse, that setCharacterEncoding never throw ISE. Rather,
it simply does nothing in the case where the request has already been accessed.

Doing this preserves backwards compatibility maximally.

[glassfishrobot]

@glassfishrobot Commented
jluehe said:
Backed out change and sent following email to Servlet EG:

---

Tightening ServletRequest.setCharacterEncoding() to throw an ISE when
invoked after getReader() has been called, or after request params
have been read (see Servlet 2.5 Issue #18,
https://servlet-spec-eg.dev.java.net/issues/show_bug.cgi?id=18), is
likely going to break backwards compatibility for many existing webapps.

In fact, it is breaking JSF completely, which has been relying on being
able to set the request encoding after having examined a request param
which identifies post-back requests. While the JSF RI team can fix
their impl to set the request encoding before examining the particular
request param, some of the plugins they support may not do so and
break.

I am sure there are many other webapps out there that are going to
break for the same reason.

If we want to tighten setCharacterEncoding() to throw an ISE, we need
to give developers more advanced notice to make their webapps compliant.

Therefore, I'd like to suggest that we relax
ServletRequest.setCharacterEncoding() to become a no-op if getReader()
has been called or request params have been read, which has been its
behaviour since this method was first introduced.

Container impls are free to log a warning message in this case, which
they should.

Following are the javadoc diffs I'm suggesting:

Index: ServletRequest.java

RCS file:
/cvs/glassfish/servlet-api/src/jakarta-servletapi-5/jsr154/src/share/javax/servlet/ServletRequest.java,v
retrieving revision 1.2
diff -u -r1.2 ServletRequest.java
— ServletRequest.java 17 Aug 2005 16:29:04 -0000 1.2
+++ ServletRequest.java 18 Aug 2005 21:21:12 -0000
@@ -163,7 +163,7 @@
/**

• Overrides the name of the character encoding used in the body of
  this

• request. This method must be called prior to reading request
  parameters

• • or reading input using getReader().
  • • or reading input using getReader(). Otherwise, it has no effect.

• @param env String containing the name of

• the character encoding.
  @@ -171,8 +171,6 @@

• ServletRequest is still in a state where a

• character encoding may be set, but the specified

• encoding is invalid

• • @throws IllegalStateException if request parameters have
• • already been read or getReader() has been called
    */
    public void setCharacterEncoding(String env) throws
    java.io.UnsupportedEncodingException;

Notice that the ISE has been added in Servlet 2.5.

Please let me know if you have any objections to this change.
Timely responses are appreciated.

[glassfishrobot]

@glassfishrobot Commented
jluehe said:
Above diffs have been applied to javax.servlet.ServletRequest in Servlet 2.5.
Therefore, I am closing this issue.

[glassfishrobot]

@glassfishrobot Commented
Was assigned to qouyang

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA GLASSFISH-23

[glassfishrobot]

@glassfishrobot Commented
Reported by @edburns

[glassfishrobot]

@glassfishrobot Commented
Marked as fixed on Thursday, May 17th 2007, 4:08:27 am