[GLASSFISH-18444] Incompatibel breaking changes to getParameter() / getPart() probably for Ticket GLASSFISH-16740 Created: 02/Mar/12  Updated: 20/Dec/16  Resolved: 09/Mar/12

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2_dev
Fix Version/s:, 4.0_dev

Type: Bug Priority: Major
Reporter: nmehner Assignee: kchung
Resolution: Fixed Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Linux version 2.6.32-38-generic

Attachments: Java Source File TestServlet.java     Java Archive File web-core.jar    
Issue Links:
blocks GLASSFISH-18505 OutOfMemory while uploading one file ... Resolved
is related to GLASSFISH-16740 Unable to get "multipart/form-data" r... Resolved
Tags: 3_1_2-next


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 (http://www.magnolia-cms.com/) where every single form stopped working in glassfish 3.1.2 with the following exception:

java.io.IOException: Corrupt form data: premature ending
at com.oreilly.servlet.multipart.MultipartParser.<init>(MultipartParser.java:205)
at com.oreilly.servlet.MultipartRequest.<init>(MultipartRequest.java:222)
at info.magnolia.cms.filters.CosMultipartRequestFilter.parseParameters(CosMultipartRequestFilter.java:101)
at info.magnolia.cms.filters.CosMultipartRequestFilter.doFilter(CosMultipartRequestFilter.java:81)
at info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:60)
at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at info.magnolia.cms.filters.ContentTypeFilter.doFilter(ContentTypeFilter.java:104)
at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:88)
at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at info.magnolia.cms.filters.ContextFilter.doFilter(ContextFilter.java:120)
at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:88)
at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at info.magnolia.cms.filters.CompositeFilter.doFilter(CompositeFilter.java:66)
at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:88)
at info.magnolia.cms.filters.MgnlMainFilter.doFilter(MgnlMainFilter.java:105)
at info.magnolia.cms.filters.MgnlMainFilter.doFilter(MgnlMainFilter.java:216)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

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.

Comment by hedes1 [ 05/Mar/12 ]

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.

Comment by james.falkner [ 06/Mar/12 ]

Liferay Portal is also running into the exact same issue. See http://issues.liferay.com/browse/LPS-25521

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.

Comment by kwutzke [ 07/Mar/12 ]

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 http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/promoted/glassfish-3.1.2-b14.zip works around this issue. The assumption of relating to GLASSFISH-16740 appears to be correct.

Comment by kchung [ 09/Mar/12 ]

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

Comment by kchung [ 09/Mar/12 ]

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.

Comment by james.falkner [ 10/Mar/12 ]

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

Comment by kwutzke [ 14/Mar/12 ]

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

Comment by sohildarshan [ 21/Mar/12 ]

Thanks. The Patch Works.

Comment by kchung [ 21/Mar/12 ]

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/StandardWrapper.java
— src/main/java/org/apache/catalina/core/StandardWrapper.java (revision 52833)+++ src/main/java/org/apache/catalina/core/StandardWrapper.java (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/Request.java
— src/main/java/org/apache/catalina/connector/Request.java (revision 52833)+++ src/main/java/org/apache/catalina/connector/Request.java (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;
    import org.apache.catalina.security.SecurityUtil;
    @@ -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/LocalStrings.properties
— src/main/resources/org/apache/catalina/connector/LocalStrings.properties (revision 52833)
+++ src/main/resources/org/apache/catalina/connector/LocalStrings.properties (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.


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
Comment by kchung [ 28/Mar/12 ]

BugDB 13899761 created for release.

Comment by robweaver [ 15/Apr/12 ]

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 ?

Comment by kchung [ 16/Apr/12 ]

robweaver, have you tried the patch?

Comment by robweaver [ 16/Apr/12 ]

Downloading http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/promoted/glassfish-3.1.2-b14.zip works around this issue.

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

Comment by kchung [ 16/Apr/12 ]

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

Comment by robweaver [ 17/Apr/12 ]

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

Comment by tmpsa [ 17/Jun/12 ]

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.

Comment by FH_Dumay [ 14/Mar/13 ]

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

Comment by haseebtahir [ 27/Aug/13 ]

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.

Comment by kchung [ 27/Aug/13 ]

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

Comment by hadrianhu [ 01/Sep/13 ]

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?

Comment by hadrianhu [ 02/Sep/13 ]

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?

Comment by kchung [ 03/Sep/13 ]

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.

Comment by taranyury [ 05/Oct/13 ]

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

Comment by octabrain [ 21/Oct/13 ]

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.

Comment by kchung [ 22/Oct/13 ]

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.

Generated at Mon Apr 24 10:09:28 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.