Re: FileUpload class not working with Tomcat 10.1
On Fri Nov 10 15:57:50 2023 Christopher Schultz
wrote:
>
> Mark,
>
> On 11/10/23 12:53, Mark Foley wrote:
> > On Fri, 10 Nov 2023 17:11:59 Mark Thomas >>
> >> On 10/11/2023 16:49, Mark Foley wrote:
> >>> I recently upgraded from Tomcat 10.0.17 to 10.1.13. ...
> >>>
> >>> [deleted]
> >>>
> >>> upgraded to 10.1.13 it is broken again! Here's the error I get:
> >>>
> >>> An error occurred at line: [40] in the jsp file:
> >>> [/schDistImportResults.jsp]
> >>> The method isMultipartContent(ServletRequestContext) is undefined for the
> >>> type FileUpload
> >>
> >> Tomcat's internal fork of Commons FileUpload isn't intended for
> >> applications to use. It is not a full fork - just a limited subset of
> >> the functionality Tomcat needs to implement the Servley upload API.
> >>
> >> [deleted]
> >
> > My current "basic" implementation is:
> >
> > <%@ page import="org.apache.tomcat.util.http.fileupload.*,
> > org.apache.tomcat.util.http.fileupload.disk.*,
> > org.apache.tomcat.util.http.fileupload.servlet.*,
> > org.apache.commons.io.*" %>
> >
> > DiskFileItemFactory factory = new DiskFileItemFactory();
> > ServletFileUpload upload = new ServletFileUpload(factory);
> > List items = upload.parseRequest(new ServletRequestContext(request));
> > Iterator iter = items.iterator();
> > FileItem item = null;
> >
> > while (iter.hasNext())
> > {
> > item = (FileItem) iter.next();
> >
> > resultsFile = new File(getServletContext().getRealPath("") +
> > "/tmp/schTaxResults.txt");
> >
> > try { item.write(resultsFile); }
> > catch ( Exception e) { out.println("Exception: " + e); }
> > }
> >
> > If you could tell me what the officially prefered Apache Tomcat FileUpload
> > mechanism is, and what the correct jar and functions are to accomplish the
> > above, I'd be
> > very grateful!
>
>
> No offense, but the above is horrifying. All that Java code in a JSP
> makes me cringe. You can do this however you want, but I'd recommend
> putting Java code into a proper servlet and letting the JSP handle
> display only.
>
> Anyway, I'll get off my soapbox.
>
> The easiest thing IMO for you to do is stop trying to parse the upload
> yourself and use the container. You must have migrated this application
> forward for like 10 years or something if you are still using a separate
> library to handle multipart-form-uploads. This has been a part of the
> code servlet API for some time, now, and you should use it:
This program was originally written 9 years ago and I just monkey-typed the
original solution from advice and help I found on the web. Likewise, when things
broke on my upgrade to Tomcat 10.0.17 I got the "how to fix" from StackOverflow.
In short, I've always depended on the kindness of strangers to get this Upload
mechaism working!
> import jakarta.servlet.http.Part;
>
> ...
>
> String contentType = request.getContentType();
> if(null == contentType || !contentType.startsWith("multipart/form-data;")) {
> logger.warn("Received non-multipart request");
>
> throw new IllegalStateException("Expected multi-part");
> }
>
> java.io.File tmpDir =
> (java.io.File)request.getServletContext().getAttribute("javax.servlet.context.tempdir");
>
> java.io.File targetFile = new java.io.File(tmpDir, "schTaxResults.txt");
>
> Part fileUpload = request.getPart("param-name");
>
> if(null != fileUpload) {
> fileUpload.write(targetFile.getAbsolutePath());
> }
I've removed my "horrifying" code and put your suggested code in place. I
replaced your:
throw new IllegalStateException("Expected multi-part");
with:
out.println("Expected multi-part");
Just to get things compiling OK. I'll deal with errors later. With that
change, it
compiled w/o problem. I then attempted an upload. The line:
if(null == contentType || !contentType.startsWith("multipart/form-data;")) {
returned TRUE so it did detect a multipart upload. Yay! That was a relief
However
Part fileUpload = request.getPart("param-name");
Gave me the error:
java.lang.IllegalStateException: Unable to process parts as no multi-part
configuration has been provided
So, what does it mean that "no multi-part configuration has been provided"? Is
"param-name" something I'm supposed to fill in? I tried substituting the
field name, "taxResults", but that gave the same error.
> I have made some obvious and not-so-obvious changes, here. First, you
> don't need a separate library: you are relying on the container for the
> multi-part handling.
>
> Second, I have changed from uploading the file directly into the servlet
> context (the live running application~) into a temporary directory. If
> you want to serve this file back out to clients, you may want to use
> WebDAV or some other protocol rather than file-upload, or maybe not.
I may revisit this after I get your basic solution working. This particular app
can upload more than one file, but first things first.
> If you want to serve this file back
RE: Accessing Credential handler inside the web application always returns null
Sorry for delayed response, Once I comment out the CredentialHandler in context
xml both in my app's context.xml and in global context.xml, and add realm to
server.xml. CredentialHandler returns null once again.
От: Christopher Schultz
Отправлено: 5 ноября 2023 г. 18:16
Кому: users@tomcat.apache.org
Тема: Re: Accessing Credential handler inside the web application always
returns null
Азат,
On 10/31/23 13:53, Усманов Азат Анварович wrote:
> Hi everyone! CredentialHandler became not null, as soon as I
> transferred Realm definition from server.xml to context.xml(after
> checking the source code) .I've been able to see the new pbkdf2
> version of the given clear text password even with old 9.0.64
> version. I was wondering is the necessity to have realm defined
> inside context. xml for accessing CredentialHandler a design decision
> or a possible bug in tomcat itself?. It wasn't mentioned in tomcat
> documentation. Perhaps it should be added in the docs.
Hmm... it shouldn't matter if you define your in server.xml or
in app/META-INF/context.xml. Are you sure that was the only difference
between working/not-working configurations?
Thanks,
-chris
>
> От: Усманов Азат Анварович
> Отправлено: 30 октября 2023 г. 20:25
> Кому: users@tomcat.apache.org
> Тема: RE: Accessing Credential handler inside the web application always
> returns null
>
> I did recheck using 9.0.82, unfortunately nothing has changed
> CredentialHandler is still null
>
> От: Christopher Schultz
> Отправлено: 30 октября 2023 г. 18:52
> Кому: Tomcat Users List ; Усманов Азат Анварович
>
> Тема: Re: Accessing Credential handler inside the web application always
> returns null
>
> Азат,
>
> On 10/29/23 20:45, Усманов Азат Анварович wrote:
>> Hi everyone!I'm trying to test CredentialHandeler functionality onour
>> test server (Tomcat 9.0.64) inside the web-app
>> I Our realm is defined as follows( excerpt from server.xml
>> )
>> > dataSourceName="jdbc/IEML_DB" roleNameCol="RoleName" userCredCol="PWD"
>> userNameCol="UserName" userRoleTable="educ.ad_UserRoles"
>> userTable="educ.ad_Users">
>> > className="org.apache.catalina.realm.NestedCredentialHandler">
>> > className="org.apache.catalina.realm.SecretKeyCredentialHandler"/>
>>> className="org.apache.catalina.realm.MessageDigestCredentialHandler"
>> algorithm="MD5" />
>>
>>
>> Currently pwd column defined as Oracle (RAW) only stores md5 hashes, I was
>> hoping to upgrade to PBKDF2 using tomcat ?so here is the relevant part
>> basic login controller code (LoginCheckServlet)
>> LoginCheckServlet
>>
>> protected void doGet(HttpServletRequest request, HttpServletResponse
>> response) throws ServletException, IOException {
>> ...
>> String userName = request.getParameter("j_username");
>> String password = request.getParameter("j_password");
>> HttpSession session = request.getSession();
>>
>> UserRecord user=... //load data from db
>> if
>> (user.checkCorrectPassword(password,session.getServletContext())) {
>> CredentialHandler
>> cr=Security.getCredentialHandler(getServletContext());
>> System.out.println(cr.mutate(password));//
>> hoping to see my password displayed as pbkdf2 hash
>>
>> .
>> }
>>
>> Security.getCredentialHandler
>>
>> public static CredentialHandler getCredentialHandler(final
>> ServletContext context) {
>> System.out.println("context"+context) ;// prints
>> contextorg.apache.catalina.core.ApplicationContextFacade@33f1f7c7
>> System.out.println("context vs"+context.getMajorVersion()); //
>> prints 4
>>
>> System.out.println("ATRIB"+context.getAttribute(Globals.CREDENTIAL_HANDLER));//always
>> prints ATRIB null
>> return (CredentialHandler)
>> context.getAttribute(Globals.CREDENTIAL_HANDLER);
>> }
>
> Your code and configuration looks reasonable to me.
>
>> So basically it always return null when trying to access
>> CredentialHandler attribute inside Security.getCredentialHandler
>> method,Any idea why it might be the case ?
> Are you able to re-try with Tomcat 9.0.70 or later? There is a
> changelog[1] entry which may be important for you:
>
> "
> Fix: Improve the behavior of the credential handler attribute that is
> set in the Servlet context so that it actually reflects what is used
> during authentication. (remm)
> "
>
> There was a problem specifically with the NestedCredentialHandler, I
> think, which was not working as expected. 9.0.70 includes a fix that
> should improve things for you.
>
> -chris
>
>
> [1]
> https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.70_(remm)
-
To unsubscribe, e-mail: users-unsubscr..
AW: FileUpload class not working with Tomcat 10.1
Hello,
> -Ursprüngliche Nachricht-
> Von: Mark Foley
> Gesendet: Sonntag, 12. November 2023 19:04
> An: users@tomcat.apache.org
> Betreff: Re: FileUpload class not working with Tomcat 10.1
>
> On Fri Nov 10 15:57:50 2023 Christopher Schultz
> wrote:
> >
> > Mark,
> >
> > On 11/10/23 12:53, Mark Foley wrote:
> > > On Fri, 10 Nov 2023 17:11:59 Mark Thomas > >>
> > >> On 10/11/2023 16:49, Mark Foley wrote:
> > >>> I recently upgraded from Tomcat 10.0.17 to 10.1.13. ...
> > >>>
> > >>> [deleted]
> > >>>
> > >>> upgraded to 10.1.13 it is broken again! Here's the error I get:
> > >>>
> > >>> An error occurred at line: [40] in the jsp file:
> > >>> [/schDistImportResults.jsp] The method
> > >>> isMultipartContent(ServletRequestContext) is undefined for the
> > >>> type FileUpload
> > >>
> > >> Tomcat's internal fork of Commons FileUpload isn't intended for
> > >> applications to use. It is not a full fork - just a limited subset
> > >> of the functionality Tomcat needs to implement the Servley upload API.
> > >>
> > >> [deleted]
> > >
> > > My current "basic" implementation is:
> > >
> > > <%@ page import="org.apache.tomcat.util.http.fileupload.*,
> > > org.apache.tomcat.util.http.fileupload.disk.*,
> > > org.apache.tomcat.util.http.fileupload.servlet.*,
> > > org.apache.commons.io.*" %>
> > >
> > > DiskFileItemFactory factory = new DiskFileItemFactory();
> > > ServletFileUpload upload = new ServletFileUpload(factory); List
> > > items = upload.parseRequest(new ServletRequestContext(request));
> > > Iterator iter = items.iterator(); FileItem item = null;
> > >
> > > while (iter.hasNext())
> > > {
> > > item = (FileItem) iter.next();
> > >
> > > resultsFile = new File(getServletContext().getRealPath("") +
> > > "/tmp/schTaxResults.txt");
> > >
> > > try { item.write(resultsFile); }
> > > catch ( Exception e) { out.println("Exception: " + e); } }
> > >
> > > If you could tell me what the officially prefered Apache Tomcat
> > > FileUpload mechanism is, and what the correct jar and functions are
> > > to accomplish the above, I'd be very grateful!
> >
> >
> > No offense, but the above is horrifying. All that Java code in a JSP
> > makes me cringe. You can do this however you want, but I'd recommend
> > putting Java code into a proper servlet and letting the JSP handle
> > display only.
> >
> > Anyway, I'll get off my soapbox.
> >
> > The easiest thing IMO for you to do is stop trying to parse the upload
> > yourself and use the container. You must have migrated this
> > application forward for like 10 years or something if you are still
> > using a separate library to handle multipart-form-uploads. This has
> > been a part of the code servlet API for some time, now, and you should
> use it:
>
> This program was originally written 9 years ago and I just monkey-typed the
> original solution from advice and help I found on the web. Likewise, when
> things broke on my upgrade to Tomcat 10.0.17 I got the "how to fix" from
> StackOverflow.
> In short, I've always depended on the kindness of strangers to get this
> Upload mechaism working!
>
> > import jakarta.servlet.http.Part;
> >
> > ...
> >
> > String contentType = request.getContentType(); if(null == contentType
> > || !contentType.startsWith("multipart/form-data;")) {
> > logger.warn("Received non-multipart request");
> >
> > throw new IllegalStateException("Expected multi-part"); }
> >
> > java.io.File tmpDir =
> > (java.io.File)request.getServletContext().getAttribute("javax.servlet.
> > context.tempdir");
> >
> > java.io.File targetFile = new java.io.File(tmpDir,
> > "schTaxResults.txt");
> >
> > Part fileUpload = request.getPart("param-name");
> >
> > if(null != fileUpload) {
> > fileUpload.write(targetFile.getAbsolutePath());
> > }
>
> I've removed my "horrifying" code and put your suggested code in place. I
> replaced your:
>
> throw new IllegalStateException("Expected multi-part");
>
> with:
>
> out.println("Expected multi-part");
>
> Just to get things compiling OK. I'll deal with errors later. With that
> change, it
> compiled w/o problem. I then attempted an upload. The line:
>
>if(null == contentType || !contentType.startsWith("multipart/form-data;"))
> {
>
> returned TRUE so it did detect a multipart upload. Yay! That was a relief
> However
>
>Part fileUpload = request.getPart("param-name");
>
> Gave me the error:
>
> java.lang.IllegalStateException: Unable to process parts as no multi-part
> configuration has been provided
>
> So, what does it mean that "no multi-part configuration has been provided"?
> Is "param-name" something I'm supposed to fill in? I tried substituting the
> field name, "taxResults", but that gave the same error.
The form element must have the attribute enctype="multipart/form-data".
Furthermore, the servlet must be annotated by "@MultipartConfig"
I think for jsp files, there is a similar setting in the web.xml.
This link might
Tomcat 10.1.15 JVM crashes randomly on startup
Greetings!
We are currently experiencing a very vague problem with our Tomcat 10.1
instance, where the JVM will crash almost instantly after Tomcat is done
starting up.
The problem happens somewhat regularly, and only happens within the first
minute after starting Tomcat. The solution is always to just attempt to restart
Tomcat and this usually only take 1 attempt.
Tomcat is running a single web application, that sees traffic over both
Websocket (several 100 clients) and Https (maybe 20-40 users during peak + a
few API clients)
Our setup is a somewhat old VM.
Windows Server 2016 Standard 1607, buil 14343.6351
Intel Xeon E5-2680 v4 @ 2.40 GHz
4 x Cores
8 GB Memory
JRE version: OpenJDK Runtime Environment Temurin-17.0.8.1+1 (17.0.8.1+1) (build
17.0.8.1+1)
Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (17.0.8.1+1, mixed mode,
sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
Tomcat version is 10.1.15 64 bit
The company we rent our VM servers from has installed Sentinel One that
connects to the JVM through an agent. I have very little knowledge of what if
anything this can do. Since this is the only thing out of the ordinary running
on this setup, my fear is that this might be causing the crashes.
I include a partial example of the exception log here, some data may have been
removed for privacy reasons. Please let med know if I should include the full
file, since I've removed parts of it due to pure length.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x1131b169, pid=2084,
tid=5160
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.8.1+1 (17.0.8.1+1)
(build 17.0.8.1+1)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (17.0.8.1+1, mixed mode,
sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# j
jakarta.servlet.http.HttpServletRequestWrapper.getDateHeader(Ljava/lang/String;)J+1
#
# Core dump will be written. Default location: E:\tomcat10\hs_err_pid2084.mdmp
#
# If you would like to submit a bug report, please visit:
# https://github.com/adoptium/adoptium-support/issues
#
--- S U M M A R Y
Command Line: -Dcatalina.home=E:\tomcat10 -Dcatalina.base=E:\tomcat10
-Dignore.endorsed.dirs=E:\tomcat10\endorsed -Djava.io.tmpdir=E:\tomcat10\temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=E:\tomcat10\conf\logging.properties
-Djava.locale.providers=COMPAT --add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.base/java.util.concurrent=ALL-UNNAMED
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED exit abort -Xms768m
-Xmx5090m -agentpath:C:\Program Files\SentinelOne\Sentinel Agent
22.3.4.612\SentinelJava64.dll
Host: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz, 4 cores, 7G, Windows Server
2016 , 64 bit Build 14393 (10.0.14393.5786)
Time: Sat Nov 11 18:18:30 2023 W. Europe Standard Time elapsed time: 153.828934
seconds (0d 0h 2m 33s)
--- T H R E A D ---
Current thread (0x2e6a9bd0): JavaThread
"https-openssl-nio-0.0.0.0-443-exec-180" daemon [_thread_in_Java, id=5160,
stack(0x403a,0x404a)]
Stack: [0x403a,0x404a], sp=0x4049c1f8, free
space=1008k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C 0x1131b169
siginfo: EXCEPTION_ACCESS_VIOLATION (0xc005), reading address
0x
...
Stack slot to memory mapping:
stack at sp + 0 slots: 0x11309657 is at code_begin+1463 in an
Interpreter codelet
return entry points [0x113090a0, 0x11309ba0] 2816 bytes
stack at sp + 1 slots: 0x0061006200650077 is an unknown value
stack at sp + 2 slots: 0x4049c208 is pointing into the stack for
thread: 0x2e6a9bd0
stack at sp + 3 slots: 0x2a938ae1 is pointing into metadata
stack at sp + 4 slots: 0x4049c268 is pointing into the stack for
thread: 0x2e6a9bd0
stack at sp + 5 slots: 0x2a93e930 is pointing into metadata
stack at sp + 6 slots: 0x0 is NULL
stack at sp + 7 slots: 0x0006c5fd67d0 is an oop: java.lang.Class
{0x0006c5fd67d0} - klass: 'java/lang/Class'
- fields (total size 14 words):
- private volatile transient 'classRedefinedCount' 'I' @12 0
- private volatile transient 'cachedConstructor'
'Ljava/lang/reflect/Constructor;' @40 NULL (0)
- private transient 'name' 'Ljava/lang/String;' @44
"jakarta.servlet.http.HttpServletRequestWrapper"{0x0006c5fd6840} (d8bfad08)
- private transient 'module' 'Ljava/lang/Module;' @48 a
'java/lang/Module'{0x0006c1d03100} (d83a0620)
- private final 'classLoader' 'Ljava/lang/ClassLoader;' @52 a
'java/net/URLClassLoader'{0x0006c1c01418} (d8380283)
- private trans
