Spring Framework
  1. Spring Framework
  2. SPR-3319

Provides a MultipartResolver that make use of Common FileUpload 1.2

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      The latest Apache FileUpload library provides an API that can handle large files without intermediary files and avoid running into memory problems. The current MutlipartResolver implementation does not support the use of this API.

        Issue Links

          Activity

          Hide
          Juergen Hoeller added a comment -

          Well, Spring's MultipartResolver abstraction assumes that a stream is pre-parsed, allowing access to specific MultipartFile objects on a random access basis. So Commons FileUpload 1.2's streaming API isn't really a natural backend for that.

          That said, nothing stops you from using Commons FileUpload directly in your Controller implementations, operating on the passed-in HttpServletRequest. Then you may of course use the streaming API if it is appropriate for your purposes.

          Juergen

          Show
          Juergen Hoeller added a comment - Well, Spring's MultipartResolver abstraction assumes that a stream is pre-parsed, allowing access to specific MultipartFile objects on a random access basis. So Commons FileUpload 1.2's streaming API isn't really a natural backend for that. That said, nothing stops you from using Commons FileUpload directly in your Controller implementations, operating on the passed-in HttpServletRequest. Then you may of course use the streaming API if it is appropriate for your purposes. Juergen
          Hide
          Narada Sage added a comment -

          Hi,

          Indeed Commons FileUpload's (CFU) streaming api is nice and one can always use that directly in the controller. However imagine this scenario. You have five controllers which were originally written using Spring's CFU support. Then if one wants to write another controller using CFU's buffered api or streaming api support directly it is not possible because the Spring multipartResolver is already declared and already depended upon by the original controllers. In the presence of the multipartResolver using CFU directly doesn't work as Spring intercepts the request first and pre-processes it leaving CFU with zero files (http://commons.apache.org/fileupload/faq.html#empty-parse). So in the current state of the code base the only way that one can use CFU's streaming api support is if they have not declared multipartResolver at all. This adds weight to SPR-3605 (http://jira.springframework.org/browse/SPR-3605) to have Spring's multipartResolver scoped somehow so that it only applies to desired controllers (through configuration) or desired http requests (through http parameters) so that's what I'd like to request.

          Thanks.

          Show
          Narada Sage added a comment - Hi, Indeed Commons FileUpload's (CFU) streaming api is nice and one can always use that directly in the controller. However imagine this scenario. You have five controllers which were originally written using Spring's CFU support. Then if one wants to write another controller using CFU's buffered api or streaming api support directly it is not possible because the Spring multipartResolver is already declared and already depended upon by the original controllers. In the presence of the multipartResolver using CFU directly doesn't work as Spring intercepts the request first and pre-processes it leaving CFU with zero files ( http://commons.apache.org/fileupload/faq.html#empty-parse ). So in the current state of the code base the only way that one can use CFU's streaming api support is if they have not declared multipartResolver at all. This adds weight to SPR-3605 ( http://jira.springframework.org/browse/SPR-3605 ) to have Spring's multipartResolver scoped somehow so that it only applies to desired controllers (through configuration) or desired http requests (through http parameters) so that's what I'd like to request. Thanks.
          Hide
          Madhava Carrillo added a comment -

          I would like to add to this thread that you can actually limit the memory used by the upload with the bean property setMaxInMemorySize:
          http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/multipart/commons/CommonsFileUploadSupport.html#setMaxInMemorySize%28int%29

          Show
          Madhava Carrillo added a comment - I would like to add to this thread that you can actually limit the memory used by the upload with the bean property setMaxInMemorySize: http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/multipart/commons/CommonsFileUploadSupport.html#setMaxInMemorySize%28int%29
          Hide
          Rossen Stoyanchev added a comment -

          This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug.

          There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it.

          If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description.

          We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.

          Show
          Rossen Stoyanchev added a comment - This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug. There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it. If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description. We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.

            People

            • Assignee:
              Juergen Hoeller
              Reporter:
              Alice
              Last updater:
              Trevor Marshall
            • Votes:
              4 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                1 year, 43 weeks, 1 day ago