[BLOSSOM-11] Implement support for multipart requests. Created: 01/Sep/10  Updated: 06/Dec/14  Resolved: 25/Sep/10

Status: Closed
Project: Blossom
Component/s: None
Affects Version/s: 1.1
Fix Version/s: 1.1.1

Type: Improvement Priority: Major
Reporter: Danilo Ghirardelli Assignee: Tobias Mattsson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File MultipartBlossom.zip    
Issue Links:
relation
is related to MAGNOLIA-3211 Multipart request filter exception on... Closed
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

Seems that at the moment multipart request are not supported by blossom integration. Magnolia already wraps the multipart request, so the standard wrapping of Spring cannot be applied anymore. Submitting a multipart form to a page with a blossom paragraph (spring controller) that expects a MultipartFile parameter will generate an error 400 from Tomcat.



 Comments   
Comment by Danilo Ghirardelli [ 01/Sep/10 ]

Trying to re-parse the multipart request will most probabily cause an error.

Comment by Danilo Ghirardelli [ 01/Sep/10 ]

In the attached file there are the three classes needed to solve the problem.

  • BlossomMultipartFile is just a wrapper of Magnolia Document that has already all the multipart data parsed.
  • BlossomMultipartResolver is an implementation of the resolver as requested by spring
  • BlossomMultipartRequestWrapper is a request wrapper that implements the interface required by spring. This is not strictly needed, because the default spring implementation can be used with the appropriate constructor, but IMHO there is a risk of repeating MAGNOLIA-3211, because parameters will be summed again.
Comment by Danilo Ghirardelli [ 01/Sep/10 ]

Obviously you are free to change the classes however you want, also the package should be adjusted (I left the one of my current project) and some license should be added.

There is still one important thing: either you should update the documentation to inform that users should add:
<bean id="multipartResolver" class="mypackage.multipart.BlossomMultipartResolver" />
to the blossom configuration, or that class should be forced automatically in the spring configuration by blossom instead of the default one.

Comment by Tobias Mattsson [ 14/Sep/10 ]

Note to self, this has to work also during pre-execution which might required the blossom filter to move back in the filter chain.

Comment by Danilo Ghirardelli [ 21/Sep/10 ]

If you ever look at this, could you also take a look at MAGNOLIA-3211? So I can finally use multipart without keeping patches...

Comment by Tobias Mattsson [ 25/Sep/10 ]

Note to self, Spring expects its MultipartRequestWrapper to be the foremost request wrapper and will reapply its wrapper if it isnt (for instance on a second execution of a DispatcherServlet where a wrapper is applied between DispatcherServlets). This isnt a problem since blossoms request wrapper dont mind being applied more than one time.

Comment by Jan Haderka [ 06/Dec/14 ]

Bulk close of old resolved issues.

Generated at Sun Feb 11 23:29:14 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.