Re: Strange error with JSP
Konstantin,
On 7/1/21 04:17, Konstantin Kolinko wrote:
вт, 29 июн. 2021 г. в 19:35, Christopher Schultz :
Konstantin,
On 6/29/21 10:21, Konstantin Kolinko wrote:
ср, 2 июн. 2021 г. в 23:16, Christopher Schultz :
[...]
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.
File dates do not matter: Tomcat resets them to match the original
file, as that is a way to track the changes. That is why I asked about
the file system and its supported time precision.
The time when the java file was generated is shown with a comment,
"Generated at: " at the top of the file.
I have two Tomcat nodes.
Node 1:
* Version: Apache Tomcat/8.5.34
* Generated at: 2021-04-08 21:22:24 UTC
I'm currently running 8.5.65, so this was certainly generated during a
previous JVM lifetime.
Note 2:
* Version: Apache Tomcat/8.5.42
* Generated at: 2021-02-27 23:04:06 UTC
Also note "_jspx_dependants.put(...)" lines in the java file. Those
are dependencies whose modification timestamps are checked as well.
Node 1:
_jspx_dependants.put("/admin/httpheaderreferences.jsp",
Long.valueOf(140008319L));
_jspx_dependants.put("/admin/util.jsp", Long.valueOf(140008319L));
_jspx_dependants.put("/admin/htmlescape.jsp",
Long.valueOf(1573394428000L));
Those dates, respectively, are:
2014-05-14 15:59:50 +
2014-05-14 15:59:50 +
2019-11-10 14:00:28 +
So... well before the launch of the JVM.
Node 2:
_jspx_dependants.put("/admin/httpheaderreferences.jsp",
Long.valueOf(156288322L));
_jspx_dependants.put("/admin/util.jsp", Long.valueOf(156288322L));
_jspx_dependants.put("/admin/htmlescape.jsp",
Long.valueOf(1573394718000L));
Those dates, respectively, are:
2019-07-11 22:13:40 +
2019-07-11 22:13:40 +
2019-11-10 14:05:18 +
So... again, well before JVM launch.
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.
I can't remember which of the 2 nodes threw this error. I may be able to
go back into the logs if it would be helpful.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange error with JSP
вт, 29 июн. 2021 г. в 19:35, Christopher Schultz : > > Konstantin, > > On 6/29/21 10:21, Konstantin Kolinko wrote: > > ср, 2 июн. 2021 г. в 23:16, Christopher Schultz > > : > [...] > > 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. File dates do not matter: Tomcat resets them to match the original file, as that is a way to track the changes. That is why I asked about the file system and its supported time precision. The time when the java file was generated is shown with a comment, "Generated at: " at the top of the file. Also note "_jspx_dependants.put(...)" lines in the java file. Those are dependencies whose modification timestamps are checked as well. > > 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. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange error with JSP
Konstantin,
On 6/29/21 10:21, Konstantin Kolinko wrote:
ср, 2 июн. 2021 г. в 23:16, Christopher Schultz :
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:
l684File base = options.getScratchDir();
l685baseUrl = base.toURI().toURL();
l686outputDir = base.getAbsolutePath() + File.separator + path +
l687File.separator;
l688if (!makeOutputDir()) {
l689throw 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
Re: Strange error with JSP
ср, 2 июн. 2021 г. в 23:16, Christopher Schultz :
>
> 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:
>
>
> l684File base = options.getScratchDir();
> l685baseUrl = base.toURI().toURL();
> l686outputDir = base.getAbsolutePath() + File.separator + path +
> l687File.separator;
> l688if (!makeOutputDir()) {
> l689throw 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
Has the page been compiled once, or its modification time is being
checked over and over, or even worse: being recompiled?
Are "webapps" and "work" directories on the same kind of file system
(with the same supported precision for file modification times)?
BTW,
A java.lang.ClassNotFoundException with
RE: Strange error with JSP
Hi Chris Was there a final resolution to this? -- Cris Berneburg CACI Senior Software Engineer -Original Message- From: Christopher Schultz Sent: Wednesday, June 2, 2021 1:52 PM To: Tomcat Users List Subject: Strange error with JSP 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. Thanks, -chris This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Strange error with JSP
Chris [major snippage] CS> app/work/Catalina/localhost/[$context]/org/apache/jsp/admin/ CS> SessionSnooper_jsp.java exist and have file-dates from way back CS> in 2016. (No recent changes) CS> This is Tomcat 8.5.65 from a stock ASF-distrubuted tarball, CS> launched using "catalina.sh start". Nothing fancy. CS> org.apache.jasper.compiler.Compiler.isOutDated(Compiler.java:464) *Something* must have changed, perhaps out of your control? I vaguely remember a few years back a customer was having a problem with a page not loading due to a compile error. The problem happened after we deployed a single-JSP fix at the same time the IT department changed the TC compiler or Java version. The problem went away eventually, I'm guessing after the IT dept did another something. Can you make a copy of the JSP and edit it in-place down to the bare minimum that it will still generate the exception? That way the new copy of the code is freshly compiled and you have the possibility of narrowing things down? IOW, if you can't figure out what it is, figure out what it is not. Is there a JAR file out of place? -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Strange error with JSP
Hi Chris cs> This is a relatively simple JSP. There are no tag libraries in use and cs> there are 3 imports of JSPs which contain some static utility functions. Sorry, no technical suggestions, but some questions... Can you load those 3 dependent JSP's in a browser via URL (or are they protected)? Are their class files there in the work folder? Was a Java upgrade installed recently? -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
Re: Strange error with JSP
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:
l684File base = options.getScratchDir();
l685baseUrl = base.toURI().toURL();
l686outputDir = base.getAbsolutePath() + File.separator + path +
l687File.separator;
l688if (!makeOutputDir()) {
l689throw new
IllegalStateException(Localizer.getMessage("jsp.error.outputfolder"));
l690}
I'm not playing any games with JSP configuration or scratch/work
directory locations, etc.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange error with JSP
Tim,
On 6/2/21 14:53, Tim Funk wrote:
My guess? ClassNotFoundException is rooted in some other exception. Such
as a different error is thrown during class initiation. Such as a static {
doStuff();} block where doStuff does bad stuff.
Hopefully there is more stack trace out there. If the JSP has static
initializers - wrap them in try {} catch blocks{} even if you think they
don't need wrapped in those blocks.
I can try that, but I was wondering about getting more information at
runtime since the system is currently angry. I'm willing to bet that if
I restart Tomcat, the error will go away.
This JSP hasn't been changed since 2016, and it's pretty reliable :)
Thanks,
-chris
On Wed, Jun 2, 2021 at 1:53 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
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.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange error with JSP
My guess? ClassNotFoundException is rooted in some other exception. Such
as a different error is thrown during class initiation. Such as a static {
doStuff();} block where doStuff does bad stuff.
Hopefully there is more stack trace out there. If the JSP has static
initializers - wrap them in try {} catch blocks{} even if you think they
don't need wrapped in those blocks.
-Tim
On Wed, Jun 2, 2021 at 1:53 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
>
> 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.
>
>
