Issue Details (XML | Word | Printable)

Key: GLASSFISH-18444
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: kchung
Reporter: nmehner
Votes: 5
Watchers: 9

If you were logged in you would be able to see more operations.

Incompatibel breaking changes to getParameter() / getPart() probably for Ticket GLASSFISH-16740

Created: 02/Mar/12 09:36 PM   Updated: 22/Oct/13 10:02 PM   Resolved: 09/Mar/12 11:42 PM
Component/s: web_container
Affects Version/s: 3.1.2_b23
Fix Version/s:, 4.0_b37

Time Tracking:
Not Specified

File Attachments: 1. Java Source File (1 kB) 02/Mar/12 09:36 PM - nmehner
2. Java Archive File web-core.jar (1.09 MB) 09/Mar/12 11:28 PM - kchung


Linux version 2.6.32-38-generic

Issue Links:

Tags: 3_1_2-next
Participants: FH_Dumay, hadrianhu, haseebtahir, hedes1, james.falkner, kchung, kwutzke, nmehner, octabrain, robweaver, sohildarshan, taranyury and tmpsa

 Description  « Hide

The attached servlet shows a problem when calling HttpServletRequest.getParameter(name) before response.getWriter()/getInputStream().

In glassfish 3.1 this used to work and print out the form data (the content of the InputStream could still be used after calling getParameter()). This has changed in glassfish 3.1.2 probably because of the changes for GLASSFISH-16740.

These changes will cause major problems in web applications that use multipart formdata, but do not yet use the getParts() method to retrieve the data, but some proprietary method. Any call to getParameter() before the files are parsed will cause the parsing of the multipart formdata to fail. I'm currently experiencing this with the Magnolia CMS ( where every single form stopped working in glassfish 3.1.2 with the following exception: Corrupt form data: premature ending
at com.oreilly.servlet.multipart.MultipartParser.<init>(
at com.oreilly.servlet.MultipartRequest.<init>(
at info.magnolia.cms.filters.CosMultipartRequestFilter.parseParameters(
at info.magnolia.cms.filters.CosMultipartRequestFilter.doFilter(
at info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(
at info.magnolia.cms.filters.MgnlFilterChain.doFilter(
at info.magnolia.cms.filters.ContentTypeFilter.doFilter(
at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(
at info.magnolia.cms.filters.MgnlFilterChain.doFilter(
at info.magnolia.cms.filters.ContextFilter.doFilter(
at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(
at info.magnolia.cms.filters.MgnlFilterChain.doFilter(
at info.magnolia.cms.filters.CompositeFilter.doFilter(
at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(
at info.magnolia.cms.filters.MgnlMainFilter.doFilter(
at info.magnolia.cms.filters.MgnlMainFilter.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.StandardWrapperValve.invoke(
at org.apache.catalina.core.StandardContextValve.invoke(
at org.apache.catalina.core.StandardPipeline.doInvoke(
at org.apache.catalina.core.StandardPipeline.invoke(
at org.apache.catalina.core.StandardHostValve.invoke(
at org.apache.catalina.connector.CoyoteAdapter.doService(
at org.apache.catalina.connector.CoyoteAdapter.service(
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(
at com.sun.grizzly.http.ProcessorTask.doProcess(
at com.sun.grizzly.http.ProcessorTask.process(
at com.sun.grizzly.http.DefaultProtocolFilter.execute(
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(
at com.sun.grizzly.DefaultProtocolChain.execute(
at com.sun.grizzly.DefaultProtocolChain.execute(
at com.sun.grizzly.http.HttpProtocolChain.execute(
at com.sun.grizzly.ProtocolChainContextTask.doCall(
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(
at com.sun.grizzly.util.AbstractThreadPool$

I think a better way to do this is to only parse the multipart formdata for Servlets that have an javax.servlet.annotation.MultipartConfig annotation. The JavaDocs for this class state:
"the Servlets annotated with MultipartConfig may retrieve the Part components of a given multipart/form-data request by calling getPart or getParts."
So servlets without this annotation should not expect the getParts() method to work anyway.

hedes1 added a comment - 05/Mar/12 12:57 PM

Same issue with richfaces when using rich:fileupload and apache common file upload.
We could not use the 3.1.2 version in production until this issue is solved.

james.falkner added a comment - 06/Mar/12 10:38 PM

Liferay Portal is also running into the exact same issue. See

We are completely broken on GlassFish 3.1.2 until this is fixed (or we work around it). Liferay code is not prepared to handle getPart()/getParts() and I'd suggest that GlassFish respect the annotations described above.

kwutzke added a comment - 07/Mar/12 07:33 PM - edited

Also running into this with RichFaces 4 fileUpload. Cannot use my current webapp on that server. Need to fall back to GF 3.1.1 until this is fixed.

EDIT: downloading works around this issue. The assumption of relating to GLASSFISH-16740 appears to be correct.

kchung added a comment - 09/Mar/12 11:28 PM

A possible fix. Drop it into <gf>/modules directory, replacing the one with the same name there.

kchung added a comment - 09/Mar/12 11:42 PM

When getParmeter() is called for multipart form data, the servlet 3.0 spec is vague on whether the container should process the multipart stuff when the servlet is not annotated with @MultipartConfig. After consulting with the servlet spec leads, we agree that web container would not process any mutipart data unless the multipart is configured either with an annotation or web.xml. The spec would be rewritten to clarify this.

Fixed in the trunk workspace.

For those who runs on 3.1.2, I've attach a jar. Just drop it into <GF>/modules directory, replacing the one there. Please try it out and let me know if that fixes the problem.

james.falkner added a comment - 10/Mar/12 02:07 PM

Confirmed that the fix works for Liferay! Thanks a bunch for the fix on trunk and the patched binary kchung!

kwutzke added a comment - 14/Mar/12 01:22 PM - edited

I can also confirm that the fix works (rich:fileUpload problem).

sohildarshan added a comment - 21/Mar/12 10:00 AM

Thanks. The Patch Works.

kchung added a comment - 21/Mar/12 06:03 PM

The fix for glassfish 3.1.2 is as the following. Note that this is not the same as the fix on the trunk, due to the differences between the two sources.

Index: src/main/java/org/apache/catalina/core/
— src/main/java/org/apache/catalina/core/ (revision 52833)+++ src/main/java/org/apache/catalina/core/ (working copy)
@@ -314,6 +314,7 @@

  • File upload (multipart) support
    + private boolean multipartConfigured = false;
    private String multipartLocation = null;
    private long multipartMaxFileSize = -1L;
    private long multipartMaxRequestSize = -1L;
    @@ -768,11 +769,15 @@
    return allow.toArray(methodNames);

+ public boolean isMultipartConfigured() { + return multipartConfigured; + }


  • Sets the multipart location
    public void setMultipartLocation(String location) { + multipartConfigured = true; multipartLocation = location; }

@@ -789,6 +794,7 @@

  • Sets the multipart max-file-size
    public void setMultipartMaxFileSize(long maxFileSize) { + multipartConfigured = true; multipartMaxFileSize = maxFileSize; }

@@ -805,6 +811,7 @@

  • Sets the multipart max-request-size
    public void setMultipartMaxRequestSize(long maxRequestSize) { + multipartConfigured = true; multipartMaxRequestSize = maxRequestSize; }

@@ -821,6 +828,7 @@

  • Sets the multipart file-size-threshold
    public void setMultipartFileSizeThreshold(int fileSizeThreshold) { + multipartConfigured = true; multipartFileSizeThreshold = fileSizeThreshold; }

Index: src/main/java/org/apache/catalina/connector/
— src/main/java/org/apache/catalina/connector/ (revision 52833)+++ src/main/java/org/apache/catalina/connector/ (working copy)
@@ -1,7 +1,7 @@

  • * Copyright (c) 1997-2011 Oracle and/or its affiliates. All rights reserved.
    + * Copyright (c) 1997-2012 Oracle and/or its affiliates. All rights reserved.
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
    @@ -78,6 +78,7 @@
    import org.apache.catalina.core.ApplicationHttpResponse;
    import org.apache.catalina.core.StandardContext;
    import org.apache.catalina.core.StandardHost;
    +import org.apache.catalina.core.StandardWrapper;
    import org.apache.catalina.deploy.LoginConfig;
    import org.apache.catalina.fileupload.Multipart;
    @@ -3147,7 +3148,8 @@
    } else { contentType = contentType.trim(); }
  • if ("multipart/form-data".equals(contentType)) {
    + if (isMultipartConfigured() &&
    + "multipart/form-data".equals(contentType)) { getMultipart().init(); }
    if (!("application/x-www-form-urlencoded".equals(contentType))) { @@ -4063,13 +4065,29 @@ return multipart; }

+ private boolean isMultipartConfigured() {
+ if (wrapper instanceof StandardWrapper) { + return ((StandardWrapper)wrapper).isMultipartConfigured(); + }
+ return false;
+ }
+ private void checkMultipartConfiguration(String name) {
+ if (! isMultipartConfigured()) { + throw new IllegalStateException( + sm.getString("coyoteRequest.multipart.not.configured", name)); + }
+ }
public Collection<Part> getParts() throws IOException, ServletException { + checkMultipartConfiguration("getParts"); return getMultipart().getParts(); }

public Part getPart(String name) throws IOException, ServletException { + checkMultipartConfiguration("getPart"); return getMultipart().getPart(name); }

Index: src/main/resources/org/apache/catalina/connector/
— src/main/resources/org/apache/catalina/connector/ (revision 52833)
+++ src/main/resources/org/apache/catalina/connector/ (working copy)
@@ -103,6 +103,7 @@
coyoteRequest.nullRemoteAddressFromProxy=PWC4013: Unable to determine client remote address from proxy (returns null)
object.invalidScope=PWC4014: Cannot use this object outside a servlet's service method or outside a filter's doFilter method
inputBuffer.streamClosed=PWC4015: Stream closed
+coyoteRequest.multipart.not.configured=PWC4016: Request.{0} is called without multipart configuration. Either add a @MultipartConfig to the servlet, or a multipart-config element to web.xml


  1. Messages related to async processing mode

kchung added a comment - 28/Mar/12 09:19 PM

BugDB 13899761 created for release.

robweaver added a comment - 15/Apr/12 02:37 PM - edited

Just updated to 3.1.2 (Build 23) and the FileUpload on PrimeFaces broke (I think due to this issue).

Upload widget acts as if the upload is working, but never hits the back end event handler.

Reverting to 3.1 with no changes to WAR and the file upload works again.

Would be glad to help diagnose this issue.

Using the b14 build mentioned above also appears to resolve this issue.

Any target date for the fix, and is there a workaround ?

kchung added a comment - 16/Apr/12 04:53 PM

robweaver, have you tried the patch?

robweaver added a comment - 16/Apr/12 09:29 PM

Downloading works around this issue.

Is there another patch you'd like me to try, or something you'd like me to trace ?

kchung added a comment - 16/Apr/12 10:58 PM

No, I was referring to the web-core.jar file that I've attached to this bug, and which worked for others.

robweaver added a comment - 17/Apr/12 03:28 AM

Confirmed - the web-core.jar does seem to correct the issue.

tmpsa added a comment - 17/Jun/12 12:05 PM

I second the confirmation - I too had broken file upload after upgrading to 3.1.2, and the patched web-core.jar solved the problem. Many thanks!

May I suggest that you add downloads of this kind of critical patches to the GF 3.1.2 download page? That would probably make a lot of users very happy.

FH_Dumay added a comment - 14/Mar/13 01:50 PM

I had the same issue with artifactory - and replacing the web-core.jar in glassfish solved the problem

haseebtahir added a comment - 27/Aug/13 10:36 AM

I have same problem, but after even replacing web-core.jar in GF-dir/modules, my problem didn't get resolved. application running into glassfish 3.1.2 (build 23) and application built on JSF 2.2, Richfaces 4.3.2, Spring 3.0 and hibernate.

Please help me in this regard.

kchung added a comment - 27/Aug/13 04:27 PM

Can you give me a small test case? Did you have the same problem with 4.0? The fix should be already in. Thanks

hadrianhu added a comment - 01/Sep/13 03:40 PM

im having the same issues with glassfish 4, when i replaced with the attached jar, glassfish crashes, does the web-core repl work for glassfish 4 as well?

hadrianhu added a comment - 02/Sep/13 05:11 AM

hi kchung, i'm having the same issue with glassfish 4? any know fixes for it? please please help, i have a deadline to finish a project and to switch to glassfish 3 at this point is just not an option ...any thoughts?

kchung added a comment - 03/Sep/13 09:58 PM

Folks, I think the fix is already in glassfish 4.0. If you still have the problem, it could be something else. I need a small test case to begin looking for a fix.

taranyury added a comment - 05/Oct/13 09:44 AM - edited

I found that this problem appears with JSF 2.2 only. And no matter which Glassfish is (3.1.2 or 4.0)

octabrain added a comment - 21/Oct/13 09:41 AM

I have the same issue with JSF 2.2 and Glassfish 4. Richfaces is the only installed framework.

I cannot switch to earlier JSF or Glassfish. It's a severe problem.

kchung added a comment - 22/Oct/13 10:02 PM

If the problem appears with JSF 2.2 only, you should file a bug with JSF, so that JSF folks can take a first look.