7

I am updating Jetty9 to Jetty11. I updated my package from javax.servlet to jakarta.servlet because servlet 5.0 is the prerequisite for Jetty11. but the problem is when I am using commons-fileupload`-1.4.jar as it is still using java.servlet package.

javax.servlet.http.HttpServletRequest.ServletFileUpload.isMultipartContent(request)

The above method is expecting argument from java.servlet package.

Latest version for commons-fileupload - https://search.maven.org/classic/#search%7Cga%7C1%7Ca%3A%22commons-fileupload%22%20AND%20g%3A%22commons-fileupload%22

Do we have any way to overcome this problem?

Joakim Erdfelt
  • 46,896
  • 7
  • 86
  • 136
Ashish Goyanka
  • 207
  • 3
  • 11

1 Answers1

6

commons-fileupload is not required from Servlet 3.1 onwards.

In fact, using commons-fileupload in combination with the a container that supports Servlet spec 3.1 (or newer) is actually not recommended.

There hasn't even been a release of commons-fileupload since 2018, and no releases that support Servlet 3.1 or newer (the last release of commons-fileupload supports Servlet 2.4 and older)

Why?

The Multipart features are built into the Servlet spec since 3.1.

Every server that supports Servlet 3.1 supports multipart file upload now.

That includes Jetty 9.

Use HttpServletRequest.getPart() API in code. You configure it via either the @MultipartConfig annotation and/or the <multipart-config> descriptor element in your WEB-INF/web.xml

See: https://docs.oracle.com/javaee/7/tutorial/servlets011.htm

See also past answers on these features.

Joakim Erdfelt
  • 46,896
  • 7
  • 86
  • 136
  • There is a small problem with Servlet API - it doesn't support `@MultipartConfig` on filters. – Lukasz Lenart Dec 28 '22 at 13:11
  • You shouldn't be reading Request content from a Filter, as that screws up the endpoint (Servlet) handling of the body content. (this even applies to using things like `HttpServletRequest.getParameter()` from a `Filter` as it breaks the ability of the Servlet to read the request body content) – Joakim Erdfelt Dec 28 '22 at 20:30
  • A `Filter`, however, can decide that the request is something it wants to handle (not the Servlet at the end of the Filter chain), in that case it uses the `RequestDispatcher.forward()` to call a specific Servlet that handles the content, bypassing the original Servlet entirely. – Joakim Erdfelt Dec 28 '22 at 20:31
  • Filters are more flexible than Servlets, anyway I found a solution how to support `@MultipartConfig` with filters just by skipping processing of the request in filter and letting servlet do the job - the config is bit more cumbersome, yet it works :) – Lukasz Lenart Dec 29 '22 at 08:24