You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2021/06/02 17:52:24 UTC
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Strange error with JSP
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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 <
> chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Strange error with JSP
Posted by Tim Funk <fu...@apache.org>.
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 <
chris@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.
>
>
RE: Strange error with JSP
Posted by "Berneburg, Cris J. - US" <cb...@caci.com.INVALID>.
Hi Chris
Was there a final resolution to this?
--
Cris Berneburg
CACI Senior Software Engineer
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Wednesday, June 2, 2021 1:52 PM
To: Tomcat Users List <us...@tomcat.apache.org>
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Strange error with JSP
Posted by "Berneburg, Cris J. - US" <cb...@caci.com.INVALID>.
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
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Konstantin,
On 7/1/21 04:17, Konstantin Kolinko wrote:
> вт, 29 июн. 2021 г. в 19:35, Christopher Schultz <ch...@christopherschultz.net>:
>>
>> Konstantin,
>>
>> On 6/29/21 10:21, Konstantin Kolinko wrote:
>>> ср, 2 июн. 2021 г. в 23:16, Christopher Schultz <ch...@christopherschultz.net>:
>> [...]
>>> 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(1400083190000L));
_jspx_dependants.put("/admin/util.jsp", Long.valueOf(1400083190000L));
_jspx_dependants.put("/admin/htmlescape.jsp",
Long.valueOf(1573394428000L));
Those dates, respectively, are:
2014-05-14 15:59:50 +0000
2014-05-14 15:59:50 +0000
2019-11-10 14:00:28 +0000
So... well before the launch of the JVM.
Node 2:
_jspx_dependants.put("/admin/httpheaderreferences.jsp",
Long.valueOf(1562883220000L));
_jspx_dependants.put("/admin/util.jsp", Long.valueOf(1562883220000L));
_jspx_dependants.put("/admin/htmlescape.jsp",
Long.valueOf(1573394718000L));
Those dates, respectively, are:
2019-07-11 22:13:40 +0000
2019-07-11 22:13:40 +0000
2019-11-10 14:05:18 +0000
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Strange error with JSP
Posted by Konstantin Kolinko <kn...@gmail.com>.
вт, 29 июн. 2021 г. в 19:35, Christopher Schultz <ch...@christopherschultz.net>:
>
> Konstantin,
>
> On 6/29/21 10:21, Konstantin Kolinko wrote:
> > ср, 2 июн. 2021 г. в 23:16, Christopher Schultz <ch...@christopherschultz.net>:
> [...]
> > 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Strange error with JSP
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Strange error with JSP
Posted by Konstantin Kolinko <kn...@gmail.com>.
ср, 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
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 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.
BTW,
I wonder whether the hard drive is reliable.
It is the only instance of Tomcat that is running with that work directory?
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.)
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Strange error with JSP
Posted by "Berneburg, Cris J. - US" <cb...@caci.com.INVALID>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Strange error with JSP
Posted by 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.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org