Re: apache tomcat 8.0.0-rc1; /manager 404; NPE
On Tue, Aug 6, 2013 at 11:34 PM, Christopher Schultz ch...@christopherschultz.net wrote: The servlet specification requires that certain services be provided by the container. Among them are a) a default servlet to serve content for which no other servlet mapping exists (e.g. static files, etc.) and b) a servlet called jsp that is, by default, mapped to *.jsp. I was not aware of that requirement, thank you for the information. Tomcat chooses to provide the above services by using conf/web.xml as a default. If you break that mechanism, you are going to lose some functionality. The webapp should be able to rely on the default and JSP servlets being available even without specifically configuring them in the webapp's own web.xml. There's actually no requirement for a web.xml for now two releases of the Servlet specification. How does the Apache Tomcat community feel about coding these core servlets with @WebServlet and let them be automatically discovered through the normal metadata-complete=false processing? Why are you deleting conf/web.xml in the first place? As I recall, it was because some web.xml fields were inherited in an additive manner, e.g. mime type mapping, and it included extra items I didn't want. And for other pieces of configuration data that were present in the conf/web.xml (DefaultServlet, and JspServlet), I had already overridden, so what is the point of keeping the global conf/web.xml.. -Jesse - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: apache tomcat 8.0.0-rc1; /manager 404; NPE
From: jieryn [mailto:jie...@gmail.com] Subject: Re: apache tomcat 8.0.0-rc1; /manager 404; NPE so what is the point of keeping the global conf/web.xml.. To allow Tomcat to work. If we changed the name to conf/do_not_delete.xml, would that satisfy you? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: apache tomcat 8.0.0-rc1; /manager 404; NPE
Greetings, On Wed, Aug 7, 2013 at 9:58 AM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: To allow Tomcat to work. If we changed the name to conf/do_not_delete.xml, would that satisfy you? I think you've quite severely missed the point of the entire discussion which I've raised. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: apache tomcat 8.0.0-rc1; /manager 404; NPE
On 07/08/2013 15:46, jieryn wrote: On Tue, Aug 6, 2013 at 11:34 PM, Christopher Schultz ch...@christopherschultz.net wrote: The servlet specification requires that certain services be provided by the container. Among them are a) a default servlet to serve content for which no other servlet mapping exists (e.g. static files, etc.) and b) a servlet called jsp that is, by default, mapped to *.jsp. I was not aware of that requirement, thank you for the information. Tomcat chooses to provide the above services by using conf/web.xml as a default. If you break that mechanism, you are going to lose some functionality. The webapp should be able to rely on the default and JSP servlets being available even without specifically configuring them in the webapp's own web.xml. There's actually no requirement for a web.xml for now two releases of the Servlet specification. How does the Apache Tomcat community feel about coding these core servlets with @WebServlet and let them be automatically discovered through the normal metadata-complete=false processing? Work is in hand to move the JSP support to a ServletContainerInitializer based configuration in Tomcat 8 onwards. The other aspects of conf/web.xml could be moved to a similar approach but there are associated knock-on effects in terms of increased start times that mean it is unlikely to happen. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: apache tomcat 8.0.0-rc1; /manager 404; NPE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jieryn, On 8/7/13 10:02 AM, jieryn wrote: Greetings, On Wed, Aug 7, 2013 at 9:58 AM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: To allow Tomcat to work. If we changed the name to conf/do_not_delete.xml, would that satisfy you? I think you've quite severely missed the point of the entire discussion which I've raised. - -1 I think Chuck's comment, while certainly snarky, is entirely appropriate: why should Tomcat change the way it establishes its default configuration? Some people like XML, some like properties, some like @Annotations, etc. You can start holy wars about all these kinds of things. In this case, history and code momentum and favors the current implementation. There just doesn't seem to be a particular reason to change things. If you have a particular reason why you think things should be changed. please make that clear. So far, you just seem to be asking why things simply are not done differently. The reason they aren't done differently is because they are done the way they are done. If there is an advantage to switching to another configuration strategy (e.g. it's harder for end-users to break things, etc.) then make your case and let the devs decide. Just don't endlessly argue your suggestion or preference without giving some reason for change. The ASF is a meritocracy: good ideas and working code rule. Academic arguments are rarely productive. If you want to produce your own patches and attach them to bugzilla issues, they may be applied, but only if you can clearly articulate why change should happen. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSAsnFAAoJEBzwKT+lPKRYI8YP/R3hCHUMXhfCglctJRWpY3Pb I5i2KuyRgBE1edUD6IkR9/TTNO/Sg9yFkH3W/Irg+MX+94KNK349Qmo9/q3kK0mb 8Q0Jvr72zL3JLi3Ljhdpej/6PZYod8HYIavPAoWjyjNNYuTGoWTdw0uyY1sQRgSX zEYjQwg5uMRKb3uvfJB9tllHhtOu86tpaeJBau5KhW/1D2/5Z5S+R1GyKUtUIjD8 +pl6lHiXtKNG141JW3S47PxBaBzfGypLq42+FsyQRoJk6R08lUkM0QbFVSCCMX3a EJ3d5s6GSFWmwT/DQPEG64PXGUz/+oLozCyj8+7JxwLzfuTLujLslrFLxf54pjl7 d40CKJD5ZwdUvswm3biO8MOycGSJjtCUQf1M7UshuJZeU9SPjj8GtnBERu1V5ogM o+MGZUk4XdApCcbzZZ8PUBmFka96OdWC4POy3evM8Bzhkqy9AtH6b859wvrIey9R KEMRWTKaLKRYcB1oo559EU1XIEvd2Jyvmb4SVrP/Bww5J7qrqn7DiKWRivjmZsMZ /vPUlcTQ6SMA3gLzP8EJZnUQXlooY1jLbgvNmyrSfwhAGirw6jPSuf7aaRzruy/v kMtKDjDAXZmOoVfVaJSuUTRwJWm10EizmiASTR40y6/aIn5HOBUW4WFbIJ1k5Hal XEGNm3xmtmIsGb8vzwTK =sJB3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
apache tomcat 8.0.0-rc1; /manager 404; NPE
When I try to hit the /manager application from a browser without specifying /html, the following NPE ends up in the log, but the browser sees what appears to be a typical tomcat 404 error page without exposing the full trace: == logs/access_log.2013-08-06 == a.b.c.d - - [06/Aug/2013:14:37:52 -0400] GET /manager HTTP/1.1 302 - a.b.c.d - tomcatadmin [06/Aug/2013:14:37:52 -0400] GET /manager/ HTTP/1.1 404 955 == logs/catalina.2013-08-06.log == 06-Aug-2013 14:37:52.862 SEVERE [http-apr-9.12.19.180-8443-exec-3] org.apache.catalina.core.StandardHostValve.custom Exception Processing ErrorPage[errorCode=404, location=/WEB-INF/jsp/404.jsp] java.lang.NullPointerException at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:456) at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:324) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:75) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:934) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:90) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:494) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1009) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:632) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:281) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2248) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2237) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614) at java.lang.Thread.run(Thread.java:779) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: apache tomcat 8.0.0-rc1; /manager 404; NPE
On 06/08/2013 20:46, jieryn wrote: When I try to hit the /manager application from a browser without specifying /html, the following NPE ends up in the log, but the browser sees what appears to be a typical tomcat 404 error page without exposing the full trace: I can't repeat this with a clean installation. Please provide the steps to reproduce from a clean 8.0.0-RC1 install. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: apache tomcat 8.0.0-rc1; /manager 404; NPE
Greetings,
On Tue, Aug 6, 2013 at 2:56 PM, Mark Thomas ma...@apache.org wrote:
On 06/08/2013 20:46, jieryn wrote:
When I try to hit the /manager application from a browser without
specifying /html, the following NPE ends up in the log, but the
browser sees what appears to be a typical tomcat 404 error page
without exposing the full trace:
I can't repeat this with a clean installation. Please provide the steps
to reproduce from a clean 8.0.0-RC1 install.
Remove the ${catalina.home}/conf/web.xml file and restart the server.
With Apache Tomcat 7.x there was no need for this conf/web.xml to be
present for the manager to work properly.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: apache tomcat 8.0.0-rc1; /manager 404; NPE
On 06/08/2013 21:53, jieryn wrote:
Greetings,
On Tue, Aug 6, 2013 at 2:56 PM, Mark Thomas ma...@apache.org wrote:
On 06/08/2013 20:46, jieryn wrote:
When I try to hit the /manager application from a browser without
specifying /html, the following NPE ends up in the log, but the
browser sees what appears to be a typical tomcat 404 error page
without exposing the full trace:
I can't repeat this with a clean installation. Please provide the steps
to reproduce from a clean 8.0.0-RC1 install.
Remove the ${catalina.home}/conf/web.xml file and restart the server.
With Apache Tomcat 7.x there was no need for this conf/web.xml to be
present for the manager to work properly.
The Tomcat 7.0.x behaviour is identical to Tomcat 8.0.x.
The root cause of the stack trace in both versions is the missing
configuration for the JSP servlet.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: apache tomcat 8.0.0-rc1; /manager 404; NPE
Greetings, On Tue, Aug 6, 2013 at 4:53 PM, Mark Thomas ma...@apache.org wrote: The Tomcat 7.0.x behaviour is identical to Tomcat 8.0.x. The root cause of the stack trace in both versions is the missing configuration for the JSP servlet. Ok, since the manager application already provides a web.xml file, shouldn't it fully specify all of its requirements? If it requires a JSP renderer servlet, it should probably state so in its deployment descriptor; for completeness and correctness. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: apache tomcat 8.0.0-rc1; /manager 404; NPE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jieryn, On 8/6/13 10:00 PM, jieryn wrote: Greetings, On Tue, Aug 6, 2013 at 4:53 PM, Mark Thomas ma...@apache.org wrote: The Tomcat 7.0.x behaviour is identical to Tomcat 8.0.x. The root cause of the stack trace in both versions is the missing configuration for the JSP servlet. Ok, since the manager application already provides a web.xml file, shouldn't it fully specify all of its requirements? If it requires a JSP renderer servlet, it should probably state so in its deployment descriptor; for completeness and correctness. The servlet specification requires that certain services be provided by the container. Among them are a) a default servlet to serve content for which no other servlet mapping exists (e.g. static files, etc.) and b) a servlet called jsp that is, by default, mapped to *.jsp. Tomcat chooses to provide the above services by using conf/web.xml as a default. If you break that mechanism, you are going to lose some functionality. The webapp should be able to rely on the default and JSP servlets being available even without specifically configuring them in the webapp's own web.xml. Why are you deleting conf/web.xml in the first place? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSAcBAAAoJEBzwKT+lPKRYqD4P/iyAY5UyHy1Idi/Yh4I+tiFE HharbiJmjqE4xsYkm1Bw48bzodFGYSPflPp5aKC7Zdc650M8+s1CeV90Ub0jaOzr 6uBHK2PrEpEGzlGhEgkW6aCV5wIpjOmGNwEH/io7wOtQ+3Qb8PGnedQQ1Z+qdrSS Kl/pxxnATSs6yzt22Z4HbSNEC2xZ5dV87YJUjrLPGj3PP1Xvf0+CuAFhHlJ6tNA5 yyLhE8KUqa0FTnI3CzBDS8RZrhh4YMY9tw8lmcffefdQY67l3HYeEPlh3L77WCv9 xiFMN/K8CpZa7wXsD1spDVkf2IQov/hPJlVhf1ZccNnMgoLVEDP55i6gYPW7Njiq JlDYuTp47vWGY9ShuCa2VRfRdOMD3C2+ZcqvCzaulrqC0zIs/7tIHv/29yL/0acW Zcg70P6kuB3tp2Eme2l/JV5FBX0sZRyb45P5zJIS6RjM8WiyXp0TijepNjHVfLik b4AK7pfR+SklPtA7Q6Kpw5fo2lYts6Op2lrYxfGHdQKw61dJP6wnllM1Rjh7YMPs aKeo939pXSURu7rwL2EC3mJDBKp+Btvt/WzmUs/MpeZBjKnDMDAZ2n0frvy//+1G 5DJPZ8LSuGlHSR9ea3IJMY60u5UNz6Q28+/1jw7Xnh38BogC1Xc6bhtrP4DKtqeb ghETsRiO14pLO9idCi9j =6D38 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
