[SOLVED] FileUpload class not working with Tomcat 10

mfoley · 03-28-2022, 09:50 AM

I've just upgraded to Tomcat 10.0.17 and things mostly seem to work OK. Except, for FileUpload. When I ran one .jsp with the following imports (which worked fine with Tomcat 9.0.41):

Code:

<%@ page import="org.apache.commons.fileupload.*,
    org.apache.commons.fileupload.disk.*,
    org.apache.commons.fileupload.servlet.*,
    org.apache.commons.io.*" %>

I got the error:

Code:

org.apache.jasper.JasperException: Unable to compile class for JSP: 

An error occurred at line: [86] in the jsp file: [/1099R-Etrans.jsp]
The type javax.servlet.http.HttpServletRequest cannot be resolved. It is indirectly referenced from required .class files
83: String programName = "$RCSfile: 1099R-Etrans.jsp,v $";
84: programName = programName.substring(programName.indexOf(':') + 2,programName.indexOf(','));
85: 
86: boolean isMultipart = FileUpload.isMultipartContent(request);

javax.servlet.http.HttpServletRequest is not specifically included in any import so I added an import for jakarta.servlet.http.HttpServletRequest, but same error.

Next, I dowloaded the latest commons-fileupload 1.4 jarfile. Then changed my imports per the class definition https://tomcat.apache.org/tomcat-10....ileUpload.html to:

Code:

<%@ page import="org.apache.tomcat.util.http.fileupload.*,
    org.apache.commons.io.*" %>

Now I get more errors:

Code:

org.apache.jasper.JasperException: Unable to compile class for JSP: 

An error occurred at line: [88] in the jsp file: [/1099R-Etrans.jsp]
The method isMultipartContent(RequestContext) in the type FileUploadBase is not applicable for the arguments (HttpServletRequest)
85: String programName = "$RCSfile: 1099R-Etrans.jsp,v $";
86: programName = programName.substring(programName.indexOf(':') + 2,programName.indexOf(','));
87: 
88: boolean isMultipart = FileUpload.isMultipartContent(request);
89: 
90: int taxYear = (request.getParameter("taxYear") == null) ? Calendar.getInstance().get(Calendar.YEAR) -1 :
91:     Integer.parseInt(request.getParameter("taxYear"));


An error occurred at line: [227] in the jsp file: [/1099R-Etrans.jsp]
DiskFileItemFactory cannot be resolved to a type
224: 
225: if (isMultipart)
226: {
227:     DiskFileItemFactory factory = new DiskFileItemFactory();   // Create a factory for disk-based file items
228:     ServletFileUpload upload = new ServletFileUpload(factory); // Create a new file upload handler
229:     List items = upload.parseRequest(request);                 // Parse the request
230:     Iterator iter = items.iterator();                          // Process the uploaded items

I feel like I'm just guessing and flailing around. Surely someone on LQ is using FileUpload and has upgrade to Tomcat 10. How do I fix this?

mfoley · 03-30-2022, 09:07 AM

Any thoughts on this? I'm currently not able to use the FileUpload class on Tomcat 10.0.17. I'm considering reverting back to 9.0.41. I've explicitly imported javax.servlet.* and javax.servlet.http.*, but I still get:

Code:

An error occurred at line: [231] in the jsp file: [/1099R-Etrans.jsp]
The type javax.servlet.http.HttpServletRequest cannot be resolved. It is indirectly referenced from required .class files
228: {
229:     DiskFileItemFactory factory = new DiskFileItemFactory();   // Create a factory for disk-based file items
230:     ServletFileUpload upload = new ServletFileUpload(factory); // Create a new file upload handler
231:     List items = upload.parseRequest(request);                 // Parse the request
232:     Iterator iter = items.iterator();                          // Process the uploaded items
233:     FileItem item = null;
234:

I'm using commons-fileupload-1.4.jar. Is that the right version for Tomcat 10.0.17?

More information ...

In examining the tomcat 9.0.41 jarfiles I find javax.servlet.http.HttpServletRequest.class in servlet-api.jar. In the 10.0.17 servlet-api.jar there are no javax... classes. There is jakarta/servlet/http/HttpServletRequest.class. There are no javax... classes in any of the 10.0.17 jarfiles.

I'm concluding that commons-fileupload-1.4.jar is out of date. I'll look for a more recent version if that's the problem. Can anyone confirm that is the problem and do you know where I could find a jakarta enabled version?

Even more information ...

According to https://commons.apache.org/proper/commons-fileupload/, version 1.4 is the latest and that was released in 23 December 2018. I've downloaded and examined the source files and they most definitely import javax.servlet.* class. So, it looks like my only recourse is to revert back to Tomcat 9 until the Commons developers get an updated FileUpload class.

That version (1.4) has not been updated since 2018. Is FileUploads obsolete? Is there something more recent that has replaced it?

boughtonp · 03-30-2022, 11:18 AM

You're using Tomcat 10 - javax.whatever is now jakarta.whatever

As per the migration notes:

Quote:

Originally Posted by https://tomcat.apache.org/migration-10.html

There is a significant breaking change between Tomcat 9.0.x and Tomcat 10.0.x. The Java package used by the specification APIs has changed from javax... to jakarta.... It will be necessary to recompile web applications against the new APIs.

mfoley · 04-06-2022, 12:13 AM

I've done that and pretty much everything works. See my solved thread https://www.linuxquestions.org/quest...ng-4175708886/. Except the FileUpload package which still references javax classes. The Commons fileupload group has no solutions for that. I'm thinking I need to revert back to Tomcat 9 until that package is updated. The most recent version, 1.4, is 3 years old.

boughtonp · 04-06-2022, 08:25 AM

Quote:

Originally Posted by mfoley

Except the FileUpload package which still references javax classes. The Commons fileupload group has no solutions for that. I'm thinking I need to revert back to Tomcat 9 until that package is updated. The most recent version, 1.4, is 3 years old.

I'm in a similar situation - despite the move from javax->jakarta being announced almost three years ago (May 2019), a servlet I use doesn't appear to have even decided if it'll make the change in the next major release (which has no eta) or the one after that. :/

Anyhow, something I've just seen in those migration notes:

Quote:

Tomcat can convert an existing web application from Java EE 8 to Jakarta EE 9 at deployment time using the Apache Tomcat migration tool for Jakarta EE. To make use of the feature, the web application should be placed in the Host legacyAppBase folder (by default named webapps-javaee) and they will be converted to an equivalent Jakarta EE web application in the Host appBase folder (by default named webapps).

Not sure if that solves your FileUpload issue, but might be worth investigating?

mfoley · 04-07-2022, 01:48 AM

boughtonp: I thought I replied to your message earlier, but I don't see it. Maybe I forgot to 'Post'. I had previously downloaded and extracted jakartaee-migration-1.0.0-bin.tar.gz, and ran jakartaee-migration-1.0.0/bin/migrate.sh, which apparently modified some jarfiles, but FileUploads still didn't work.

Anyway, problem solved per my thread https://www.linuxquestions.org/quest...ss-4175710186/.

As mentioned, I had been using the org.apache.commons.fileupload package, but the most recent version, 1.4, was released 23 December 2018; certainly before the whole javax -> jakarta thing. So, I changed to using org.apache.tomcat.util.http.fileupload. That above referenced thread shows the imports I needed and a needed call to ServletRequestContext(), but it all now works.

I always include some standard imports in all my JSP programs:

Code:

<%@ page import="javax.naming.Context,
  javax.naming.NamingException,
  jakarta.servlet.http.Cookie,
  java.sql.*,
  java.lang.String, java.lang.Object,
  java.io.*, java.util.*" %>

The jakarta.servlet.http.Cookie import was the only one I needed to change from javax to get Tomcat 10 working. Interestingly, changing javax.naming.Context and javax.naming.NamingException, to jakarta.naming.Context and jakarta.naming.NamingException wouldn't compile. I had to leave them as javax. The only references I found to these classes in Tomcat 10 $CATALINA_HOME/lib was in ecj-4.20.jar, and it has the entry: "META-INF/services/javax.tools.JavaCompiler". I'm not going to expend time drilling down on this, but it appears the naming class is still operating under javax and that META-INF entry must have something to do with reconciling this class. Does anyone have any insight into this? I'd be curious to know, even though my problem is solved.

boughtonp · 04-07-2022, 07:44 AM

My understanding is that there are still a few javax packages in the JVM itself, the javax->jakarta rename only occurred in what was called "Java EE" and is now called "Jakarta EE" - i.e. servlets etc.

mfoley · 04-08-2022, 07:50 PM

Quote:

Originally Posted by boughtonp

My understanding is that there are still a few javax packages in the JVM itself, the javax->jakarta rename only occurred in what was called "Java EE" and is now called "Jakarta EE" - i.e. servlets etc.

I upgrade Tomcat regularly and I'd love to know where your "understanding" comes from. I don't find such information in the release notes. Are you gleaning this from other blogs or forums? Is there one or two in particular that you favor for this esoterica? Each time I upgrade, if there are important changes like this, it take me days to track down all the reasons why and things I need to change. I'd love for there to be a few key places where I can get the "scoop" and not struggle so much.

Thanks in advance

boughtonp · 04-09-2022, 08:31 AM

If I could cite a specific source I would have done so, but it is logical since only "Java EE" was affected, so everything else didn't have the legal requirement to change.

I switched from Tomcat to Jetty a while back, and so it the Jetty release announcements mailing list I subscribe to, and when something seems interesting/relevant I search for further information about it - most likely that's where this came from.

It's easy to confirm that there are still Java SE classes using the javax namespace, for example see Oracle's Java 17 docs for java.desktop - i.e. the module containing Swing, which still uses javax.swing namespace.

mfoley · 04-13-2022, 12:11 PM

Quote:

Originally Posted by boughtonp

If I could cite a specific source I would have done so, but it is logical since only "Java EE" was affected, so everything else didn't have the legal requirement to change.

Well, not so logical to me. Although I have to install tomcat, I'm not a deep-diving experts and it's not obvious to someone at my level that changes to "Java EE" would naturally NOT affect anything else (why would the Naming class be obviously not "Java EE" for example? -- rhetorical, no need to answer).

Bottom line is that you did a bit of research and subscribe to a list whereby you collect information. Apparently there is no single place (other than LQ) that tells upgraders what to look out for.

In this particular case, figuring it out wasn't hard. I had changed javax.naming, to jakarta.naming and, when that didn't work, I changed it back, and it worked.

Thanks again for the info.