Mark and Chuck,
On 5/9/24 09:35, Chuck Caldarale wrote:
You need the web.xml entries because you have extra configuration
items (the <multipart-config> settings) that aren’t part of the
default JSP servlet definition.
+1
If you didn't need to upload files to your JSP, you wouldn't have needed
any of this in your web.xml file.
It's very weird to do this kind of logic in a JSP. I *highly* recommend
that you split your JSP into at least two pieces:
1. A servlet that handles the upload, produces no output, and handles
error conditions gracefully. It then forwards or redirects (as
appropriate) to the page you want to display post-upload. You will need
to map this servlet in web.xml, but it's less-stupid than mapping a JSP
to a servlet-name and then mapping that same servlet-name back to a URL
pattern which is the same as the JSP's path. I can see why you were
saying "I have no idea why this is necessary": it seems useless but you
must attach the file-upload metadata to something, and this is how you
do it.
Note that you didn't have to do it that way. You could have done this:
<servlet>
<servlet-name>uploadfile</servlet-name>
<jsp-file>/schDistImports.jsp</jsp-file>
...
</servlet>
<servlet-mapping>
<servlet-name>uploadfile</servlet-mapping>
<url-pattern>/schDistImports</url-pattern> NOTE: no .jsp extension
</servlet-mapping>
In your case, the generic name "uploadfile" for a very specific type of
upload (schDistImports) might be a mistake, since you might want to
upload all kinds of files, such as 1099 forms or whatnot. One called
"uploadfile" seems generic when it's not really generic: it's specific
to that one workflow.
You can use any name you like. You can use any URL pattern you like as
well, such as /sch/dist/imports. You don't have to be tied to your
filesystem layout.
2. A page template (JSP is fine) that only generates page content. No
mapping in web.xml is necessary for this, which is probably what you are
used to.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org