Konstantin,
On 6/29/21 10:21, Konstantin Kolinko wrote:
ср, 2 июн. 2021 г. в 23:16, Christopher Schultz <ch...@christopherschultz.net>:
All,
On 6/2/21 13:52, Christopher Schultz wrote:
All,
I don't do too much work with JSPs, but I do have a few quick-and-dirty
administrative things including one called the "session snooper" which
just dumps out loads of information about the current user's session
object.
I'm getting this error in production, and I can reproduce it every time
I access the page. Here's the exception stack trace:
java.lang.ClassNotFoundException: org.apache.jsp.admin.SessionSnooper_jsp
java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:128)
at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:59)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:159)
at
org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:192)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:413)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
[...filters, etc...]
This is a relatively simple JSP. There are no tag libraries in use and
there are 3 imports of JSPs which contain some static utility functions.
Both files
app/work/Catalina/localhost/[$context]/org/apache/jsp/admin/SessionSnooper_jsp.java
and
app/work/Catalina/localhost/[$context]/org/apache/jsp/admin/SessionSnooper_jsp.java
exist and have file-dates from way back in 2016. (No recent changes)
The context has been restarted/reloaded (not redeployed) recently using
JMX a few times, but nothing else relevant comes to mind.
This is Tomcat 8.5.65 from a stock ASF-distrubuted tarball, launched
using "catalina.sh start". Nothing fancy.
What other information can I collect to help debug this? My expectation
would be that the class should be findable and runnable. Tomcat should
not be tripping over its own feet on this one IMO.
There is more in my catalina.out file:
Jun 02, 2021 4:12:27 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [jsp] in context with path
[/[$context]] threw exception [java.lang.NullPointerException] with root
cause
java.lang.NullPointerException
at
org.apache.jasper.JspCompilationContext.createOutputDir(JspCompilationContext.java:685)
at
org.apache.jasper.JspCompilationContext.getOutputDir(JspCompilationContext.java:204)
at
org.apache.jasper.JspCompilationContext.getClassFileName(JspCompilationContext.java:537)
at
org.apache.jasper.compiler.Compiler.isOutDated(Compiler.java:464)
at
org.apache.jasper.compiler.Compiler.isOutDated(Compiler.java:430)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:590)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
Here's the code from createOutputDir:
l684 File base = options.getScratchDir();
l685 baseUrl = base.toURI().toURL();
l686 outputDir = base.getAbsolutePath() + File.separator + path +
l687 File.separator;
l688 if (!makeOutputDir()) {
l689 throw new
IllegalStateException(Localizer.getMessage("jsp.error.outputfolder"));
l690 }
I'm not playing any games with JSP configuration or scratch/work
directory locations, etc.
Looking at line 685,
It is odd:
If options.getScratchDir() were returning null, you would see fatal
errors in your log earlier: The "options" variable should be an
instance of o.a.j.EmbeddedServletOptions. Its constructor initializes
the scratchDir field, does some checks and logs with log.fatal() when
the dir is null or not readable and writable.
A java.io.File.toURI() call cannot return null: the only possible
returned value is a new object, "new URI(...)" (looking into the
sources from Java 8u292).
BTW, I wonder whether your JspServlet is configured "for production",
http://tomcat.apache.org/tomcat-8.5-doc/jasper-howto.html#Production_Configuration
Unfortunately, I have restarted (or possibly reloaded) the server since
then and can no longer replicate the error. But I'm happy to answer
questions if it helps zero-in on a bug in Tomcat. I think there's
definitely someting that CAN go wrong but shouldn't. So I think there is
a bug hidden, here, somewhere.
I have no special configuration for JSP in my application: it's whatever
the defaults are that ship with a stock Tomcat. We don't use JSPs
heavily, and those JSPs we do use are only used by administrators so
they get very low-volume usage.
Has the page been compiled once, or its modification time is being
checked over and over, or even worse: being recompiled?
Probably not being recompiled. The source JSP has a file-date in 2016
and the generated .java and .class files also have a date in 2016.
Are "webapps" and "work" directories on the same kind of file system
(with the same supported precision for file modification times)?
Exactly the same filesystem.
BTW,
A java.lang.ClassNotFoundException with no "original cause" likely
means that a getResource() call failed. Note that debug logging can be
turned on for that call, as the getResource() method is implemented by
o.a.catalina.loader.WebappClassLoaderBase class.
I have been "reloading" my web application more often recently for
hot-fixes, etc. Normally, I would shut down the JVM, do an upgrade, and
start it back up again. But I've been expreimenting with reloading. The
JSP files are not being modified as a part of the reload; .class files
in WEB-INF/classes and sometimes a .jar file in WEB-INF/lib changes only.
No other problematic behaviors that I can see. I'm not using
parallel-deployment; this is just reloading the webapp's context directly.
BTW,
I wonder whether the hard drive is reliable.
I have no current reasons to be suspicious of these disks. I'm running
on Linux with a mirrored software RAID configuration (md/lvm).
It is the only instance of Tomcat that is running with that work directory?
Yes. There is no file contention, etc.
The only instance of web application? (The scratchDir can be
configured. If it has been, several instances of the same web
application may share it.)
I have multiple Tomcats running on the same server, but all serving
different applications out of separate CATALINA_BASE locations. They
share a CATALINA_HOME.
Thanks,
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
