error-page directive
Hello all, I have a web.xml (attached) that works fine if I remove the error-page directive, but gives a Exception initializing TldLocationsCache: XML parsing error on file /WEB-INF/web.xml: (line 72, col 11): The content of element type web-app must match (icon?,display-name?,description?,distributable?,context-param*,servlet*,servlet-mapping*,session-config?,mime-mapping*,welcome-file-list?,error-page*,taglib*,resource-ref*,security-constraint*,login-config?,security-role*,env-entry*,ejb-ref*). message when the indicated (java.lang.ClassNotFoundException) is encountered. I checked docs and books, but I can't find anything wrong with the web.xml. The template web.xml I used is the one from the struts 1.2.4 package. Could anyone please tell me what is wrong with this deployment descriptor? Thank you very much in advance for any input, Ian. ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app display-nameKNMI Operational DataCenter/display-name !-- Standard Action Servlet Configuration (with debugging) -- servlet servlet-nameaction/servlet-name servlet-classorg.apache.struts.action.ActionServlet/servlet-class init-param param-nameconfig/param-name param-value/WEB-INF/struts-config.xml/param-value /init-param init-param param-namedebug/param-name param-value3/param-value /init-param init-param param-namedetail/param-name param-value3/param-value /init-param load-on-startup3/load-on-startup /servlet !-- Standard Action Servlet Mapping -- servlet-mapping servlet-nameaction/servlet-name url-pattern*.do/url-pattern /servlet-mapping !-- The Usual Welcome File List -- welcome-file-list welcome-fileindex.jsp/welcome-file /welcome-file-list !-- Struts Tag Library Descriptors -- taglib taglib-uri/tags/struts-bean/taglib-uri taglib-location/WEB-INF/struts-bean.tld/taglib-location /taglib taglib taglib-uri/tags/struts-html/taglib-uri taglib-location/WEB-INF/struts-html.tld/taglib-location /taglib taglib taglib-uri/tags/struts-logic/taglib-uri taglib-location/WEB-INF/struts-logic.tld/taglib-location /taglib taglib taglib-uri/tags/struts-nested/taglib-uri taglib-location/WEB-INF/struts-nested.tld/taglib-location /taglib taglib taglib-uri/tags/struts-tiles/taglib-uri taglib-location/WEB-INF/struts-tiles.tld/taglib-location /taglib error-page exception-typejava.lang.ClassNotFoundException/exception-type location/pages/apperror.jsp/location /error-page /web-app - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page directive
Hi, Have you tried to move your the error-page directive to between the welcome-file-list and taglib directives. Seem to remember this happening to me some time ago as well. Trond !-- The Usual Welcome File List -- welcome-file-list welcome-fileindex.jsp/welcome-file /welcome-file-list error-page exception-typejava.lang.ClassNotFoundException/exception-type location/pages/apperror.jsp/location /error-page !-- Struts Tag Library Descriptors -- taglib taglib-uri/tags/struts-bean/taglib-uri taglib-location/WEB-INF/struts-bean.tld/taglib-location /taglib /web-app - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page directive
On Tue, 01 Mar 2005 10:32:42 +0100, Trond G. Ziarkowski [EMAIL PROTECTED] wrote: Hi, Have you tried to move your the error-page directive to between the welcome-file-list and taglib directives. Seem to remember this happening to me some time ago as well. That seems to get rid of the message, but it doesn't seem to honour the directive, because I still get tomcats default exception stacktrace page. Thank you so far, it's much appreciated, Ian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page directive
Perhaps, try to put error-page BEFORE taglib... On Tue, 1 Mar 2005 10:07:49 +0100 Ian van der Neut [EMAIL PROTECTED] wrote: Hello all, I have a web.xml (attached) that works fine if I remove the error-page directive, but gives a Exception initializing TldLocationsCache: XML parsing error on file /WEB-INF/web.xml: (line 72, col 11): The content of element type web-app must match (icon?,display-name?,description?,distributable?,context-param*,servlet*,servlet-mapping*,session-config?,mime-mapping*,welcome-file-list?,error-page*,taglib*,resource-ref*,security-constraint*,login-config?,security-role*,env-entry*,ejb-ref*). message when the indicated (java.lang.ClassNotFoundException) is encountered. I checked docs and books, but I can't find anything wrong with the web.xml. The template web.xml I used is the one from the struts 1.2.4 package. Could anyone please tell me what is wrong with this deployment descriptor? Thank you very much in advance for any input, Ian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page directive
On Tue, 1 Mar 2005 10:41:36 +0100, Ian van der Neut [EMAIL PROTECTED] wrote: On Tue, 01 Mar 2005 10:32:42 +0100, Trond G. Ziarkowski [EMAIL PROTECTED] wrote: Hi, Have you tried to move your the error-page directive to between the welcome-file-list and taglib directives. Seem to remember this happening to me some time ago as well. That seems to get rid of the message, but it doesn't seem to honour the directive, because I still get tomcats default exception stacktrace page. The fact that it is not honoured seems to be because of a problem in the apperror.jsp file. Moving the error-page directive before the taglib directive solves the problem indeed. Just curious, does order matter in web.xml? If so, where is this documented? Or is this just a bug? Thank you very much, Ian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page directive
Hi, the order does matter, and the order is specified in the dtd that you are using for your webapp. Trond Ian van der Neut wrote: On Tue, 1 Mar 2005 10:41:36 +0100, Ian van der Neut [EMAIL PROTECTED] wrote: On Tue, 01 Mar 2005 10:32:42 +0100, Trond G. Ziarkowski [EMAIL PROTECTED] wrote: Hi, Have you tried to move your the error-page directive to between the welcome-file-list and taglib directives. Seem to remember this happening to me some time ago as well. That seems to get rid of the message, but it doesn't seem to honour the directive, because I still get tomcats default exception stacktrace page. The fact that it is not honoured seems to be because of a problem in the apperror.jsp file. Moving the error-page directive before the taglib directive solves the problem indeed. Just curious, does order matter in web.xml? If so, where is this documented? Or is this just a bug? Thank you very much, Ian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page directive
The order matters. It's a requirement that comes from validating the web.xml against a DTD -- not anything that Tomcat itself requires. In the servlet 2.4 spec, they moved to valdating against a schema so order no longer matters. --David Ian van der Neut wrote: On Tue, 1 Mar 2005 10:41:36 +0100, Ian van der Neut [EMAIL PROTECTED] wrote: On Tue, 01 Mar 2005 10:32:42 +0100, Trond G. Ziarkowski [EMAIL PROTECTED] wrote: Hi, Have you tried to move your the error-page directive to between the welcome-file-list and taglib directives. Seem to remember this happening to me some time ago as well. That seems to get rid of the message, but it doesn't seem to honour the directive, because I still get tomcats default exception stacktrace page. The fact that it is not honoured seems to be because of a problem in the apperror.jsp file. Moving the error-page directive before the taglib directive solves the problem indeed. Just curious, does order matter in web.xml? If so, where is this documented? Or is this just a bug? Thank you very much, Ian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: error-page directive
Hi, again. I don't really think it makes any difference to this application, but I'm using J2SE, not J2EE. Though I am, of course, using a web.xml file for my web application, nothing in this file need reference the error page. At least, that was the case with version 2.3 of the servlet API under Tomcat 4.1, since the error page worked faultlessly under that. Is 2.4 more restrictive? Is an error-page tag now mandatory? Is this change documented? Since I currently have only servlet and servlet-mapping tags in my web.xml, can I simply place the tag where I wish? Sorry for the proliferation of fairly trivial questions. Thanks in anticipation. Cheers. Jan -Original Message- From: David Smith [mailto:[EMAIL PROTECTED] Sent: 01 March 2005 13:27 To: Tomcat Users List Subject: Re: error-page directive The order matters. It's a requirement that comes from validating the web.xml against a DTD -- not anything that Tomcat itself requires. In the servlet 2.4 spec, they moved to valdating against a schema so order no longer matters. --David Ian van der Neut wrote: On Tue, 1 Mar 2005 10:41:36 +0100, Ian van der Neut [EMAIL PROTECTED] wrote: On Tue, 01 Mar 2005 10:32:42 +0100, Trond G. Ziarkowski [EMAIL PROTECTED] wrote: Hi, Have you tried to move your the error-page directive to between the welcome-file-list and taglib directives. Seem to remember this happening to me some time ago as well. That seems to get rid of the message, but it doesn't seem to honour the directive, because I still get tomcats default exception stacktrace page. The fact that it is not honoured seems to be because of a problem in the apperror.jsp file. Moving the error-page directive before the taglib directive solves the problem indeed. Just curious, does order matter in web.xml? If so, where is this documented? Or is this just a bug? Thank you very much, Ian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page directive
For good docs, I've found the servlet spec an excellent place to start. As a foot note though, Tomcat seems switches between servlet spec 2.3 and 2.4 depending on how the web-app node is defined in web.xml. If you declare it against the 2.3 DTD, the 2.3 spec is used. If you use the 2.4 schema, 2.4 spec is adhered to. See the spec for how each is declared in web.xml. Servlet spec 2.3: http://www.jcp.org/en/jsr/detail?id=53 Servlet spec 2.4: http://www.jcp.org/en/jsr/detail?id=154 --David Graba, Jan wrote: Hi, again. I don't really think it makes any difference to this application, but I'm using J2SE, not J2EE. Though I am, of course, using a web.xml file for my web application, nothing in this file need reference the error page. At least, that was the case with version 2.3 of the servlet API under Tomcat 4.1, since the error page worked faultlessly under that. Is 2.4 more restrictive? Is an error-page tag now mandatory? Is this change documented? Since I currently have only servlet and servlet-mapping tags in my web.xml, can I simply place the tag where I wish? Sorry for the proliferation of fairly trivial questions. Thanks in anticipation. Cheers. Jan -Original Message- From: David Smith [mailto:[EMAIL PROTECTED] Sent: 01 March 2005 13:27 To: Tomcat Users List Subject: Re: error-page directive The order matters. It's a requirement that comes from validating the web.xml against a DTD -- not anything that Tomcat itself requires. In the servlet 2.4 spec, they moved to valdating against a schema so order no longer matters. --David Ian van der Neut wrote: On Tue, 1 Mar 2005 10:41:36 +0100, Ian van der Neut [EMAIL PROTECTED] wrote: On Tue, 01 Mar 2005 10:32:42 +0100, Trond G. Ziarkowski [EMAIL PROTECTED] wrote: Hi, Have you tried to move your the error-page directive to between the welcome-file-list and taglib directives. Seem to remember this happening to me some time ago as well. That seems to get rid of the message, but it doesn't seem to honour the directive, because I still get tomcats default exception stacktrace page. The fact that it is not honoured seems to be because of a problem in the apperror.jsp file. Moving the error-page directive before the taglib directive solves the problem indeed. Just curious, does order matter in web.xml? If so, where is this documented? Or is this just a bug? Thank you very much, Ian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
error-page directive gives a wrong response code to apache
hi everyone, I have a problem with the error-page directive included in my web.xml The RPM's I use on a Linux RedHat top box : apache-1.3.27-2.7.1 tomcat4-4.1.18-full.1jpp mod_jk-ap13-1.2.2-1jpp so when apache gives a jsp to Tomcat, this one answers a code 200 instead of a 404 in the apache log even if the jsp is not found ... I know this bug is in the bugzilla database as RESOLVED yet ( http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15406 ) but for 4.1.12 version so I can't understand what happens ... the interesting part of my web.xml : error-page error-code403/error-code location/error/403.jsp/location /error-page error-page error-code404/error-code location/error/404.jsp/location /error-page ## has anyone an idea ? thanks in advance, Julien OIX Service Informatique de Gestion - Université de Nantes Tel: 02 40 99 83 65 / abroad + (33) 240 99 83 65 Web: http://www.univ-nantes.fr mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page directive gives a wrong response code to apache
If you have a custom error page, its the job of the page to explicitly set the error code. This is because errors may *not* be errors and the error page may have logic to recover from various errors. You'll see this behavior in other servlet engines too. In your error page, you'll need this snippet: %response.setStatus(HttpServletResponse.SC_NOT_FOUND);% -Tim Julien Oix wrote: hi everyone, I have a problem with the error-page directive included in my web.xml The RPM's I use on a Linux RedHat top box : apache-1.3.27-2.7.1 tomcat4-4.1.18-full.1jpp mod_jk-ap13-1.2.2-1jpp so when apache gives a jsp to Tomcat, this one answers a code 200 instead of a 404 in the apache log even if the jsp is not found ... I know this bug is in the bugzilla database as RESOLVED yet ( http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15406 ) but for 4.1.12 version so I can't understand what happens ... the interesting part of my web.xml : error-page error-code403/error-code location/error/403.jsp/location /error-page error-page error-code404/error-code location/error/404.jsp/location /error-page ## - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page directive gives a wrong response code to apache
Julien Oix wrote: hi everyone, I have a problem with the error-page directive included in my web.xml The RPM's I use on a Linux RedHat top box : apache-1.3.27-2.7.1 tomcat4-4.1.18-full.1jpp mod_jk-ap13-1.2.2-1jpp so when apache gives a jsp to Tomcat, this one answers a code 200 instead of a 404 in the apache log even if the jsp is not found ... I know this bug is in the bugzilla database as RESOLVED yet ( http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15406 ) but for 4.1.12 version so I can't understand what happens ... It is RESOLVED INVALID. In other words: That behaviour is considered correct. If You want Your JSP to return a response code different from 200 You have to include: % response.setStatus(response.SC_NOT_FOUND); % in Your 404-page. Regards, Johann Uhrmann -- Johann Uhrmann xpecto AG | Lindenstrasse 81 | D-84030 Ergolding Telefon: 0700 xpecto 00 (0700 973286 00) Telefax: 0700 xpecto 10 (0700 973286 10) Internet: http://www.xpecto.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: error-page directive gives a wrong response code to apache
it works great ! thanks a lot for your tip's, both Tim Johann :-) Julien OIX Service Informatique de Gestion - Universite de Nantes Tel: 02 40 99 83 65 / abroad + (33) 240 99 83 65 Web: http://www.univ-nantes.fr mailto:[EMAIL PROTECTED] -Message d'origine- De : Tim Funk [mailto:[EMAIL PROTECTED] Envoye : mercredi 22 octobre 2003 14:25 A : Tomcat Users List Objet : Re: error-page directive gives a wrong response code to apache If you have a custom error page, its the job of the page to explicitly set the error code. This is because errors may *not* be errors and the error page may have logic to recover from various errors. You'll see this behavior in other servlet engines too. In your error page, you'll need this snippet: %response.setStatus(HttpServletResponse.SC_NOT_FOUND);% -Tim Julien Oix wrote: hi everyone, I have a problem with the error-page directive included in my web.xml The RPM's I use on a Linux RedHat top box : apache-1.3.27-2.7.1 tomcat4-4.1.18-full.1jpp mod_jk-ap13-1.2.2-1jpp so when apache gives a jsp to Tomcat, this one answers a code 200 instead of a 404 in the apache log even if the jsp is not found ... I know this bug is in the bugzilla database as RESOLVED yet ( http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15406 ) but for 4.1.12 version so I can't understand what happens ... the interesting part of my web.xml : error-page error-code403/error-code location/error/403.jsp/location /error-page error-page error-code404/error-code location/error/404.jsp/location /error-page ## - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
error-page directive ignored
Hello I have tomcat 4.1.27 RedHat 9 Sun jdk 1.4.2_01 Mozilla Firebird 0.7 here is the snippet from my web.xml servlet servlet-nameGeneralErrorServlet/servlet-name servlet-classcom.silkroad.srm.GeneralErrorServlet/servlet-class /servlet servlet-mapping servlet-nameGeneralErrorServlet/servlet-name url-pattern/generalerror/url-pattern /servlet-mapping error-page exception-typejava.lang.Throwable/exception-type location/generalerror/location /error-page . here is the snippet from a servlet that is located in this web application . TreeMap attrs=null; Stack steps=null; attrs.get(something); .. this code obviusly throws NPE, but tomcat ignores it and instead of dispatching to GeneralErrorServlet StackTrace is displayed in the browser. The resource did not process correctly java.lang.NullPointerException at com.silkroad.srm.CreateMessageServlet.processRequest(CreateMessageServlet.java:63) at com.silkroad.srm.CreateMessageServlet.doGet(CreateMessageServlet.java:231) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at com.silkroad.commons.filters.ActionFilter.doFilter(ActionFilter.java:170) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at com.silkroad.srm.filters.IPFilter.doFilter(IPFilter.java:159) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at com.silkroad.commons.filters.EncodingFilter.doFilter(EncodingFilter.java:126) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2416) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:577) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1040) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1151) at java.lang.Thread.run(Thread.java:534) I have a question: is this because of a filter that is applied to this servlet?. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: error-page directive ignored
The location of the error page must be a real page and not a servlet. (But a jsp will work too) With tomcat5 (actually servlet api 2.4), your error page can be a servlet. -Tim Vano Beridze wrote: Hello I have tomcat 4.1.27 RedHat 9 Sun jdk 1.4.2_01 Mozilla Firebird 0.7 here is the snippet from my web.xml servlet servlet-nameGeneralErrorServlet/servlet-name servlet-classcom.silkroad.srm.GeneralErrorServlet/servlet-class /servlet servlet-mapping servlet-nameGeneralErrorServlet/servlet-name url-pattern/generalerror/url-pattern /servlet-mapping error-page exception-typejava.lang.Throwable/exception-type location/generalerror/location /error-page - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page directive
Which versions of IE is that applicable to? (Graham Reeds) Sorry for the delay. IE v 6.0.2600 Regards, Carlos Pereira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page directive
I recall there was an issue with some version of IE: it had a feature: if the error page is less then x bytes then IE showes its ugly default error page. But if the error page is large enough (in terms of bytes) then it showes that. (Anton Tagunov) You are right! IE shows its default error page if the messages has 341 chars or less. From 342 chars up, it shows the received data. Thanks! My problem is solved. Please let us know if this works. If it does it is worth adding to the faq. I agree. Explaining IE's behaviour should clarify all. By the way, Netscape doesn't do this... Best regards, Carlos Pereira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page directive
I recall there was an issue with some version of IE: it had a feature: if the error page is less then x bytes then IE showes its ugly default error page. But if the error page is large enough (in terms of bytes) then it showes that. (Anton Tagunov) You are right! IE shows its default error page if the messages has 341 chars or less. From 342 chars up, it shows the received data. Thanks! My problem is solved. Which versions of IE is that applicable to? G. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page directive
Hello Carlos! CP IE shows it's default Error 500 - Internal Server Error page. I recall there was an issue with some version of IE: it had a feature: if the error page is less then x bytes then IE showes its ugly default error page. But if the error page is large enough (in terms of bytes) then it showes that. I recall (I was at it several years ago) that Cocoon machinery for reporting errors was on purpose filling the error report to be large enough somehow (probably it was sipmply adding spaces, don't remember). So, try to use a _really large_ page as your error page. Please let us know if this works. If it does it is worth adding to the faq. Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
error-page directive
I am using Tomcat 4.1.24 in Windows XP and I cannot define an error page. I have defined it in web.xml as error-page error-code500/error-code location/errorpage.hmtl/location /error-page and none of them works. The page displayed is Tomcat's default error page. The error-page tag seems to be simply ignored, as no errors are found in the application initialization. If I use error-page exception-typejava.lang.Throwable/exception-type location/errorpage.html/location /error-page and throw an exception, like RuntimeException, IE shows it's default Error 500 - Internal Server Error page. I tried to put errorpage.html both in the server's root and the application's context root. It doesn't work. I tried switching the location for a servlet mapping, like /error. It doesn´t work. I upgraded Tomcat to 5.0.12. The result is the same. So, what's the problem? Regards, Carlos Pereira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page directive
- Original Message - From: Carlos Pereira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 03, 2003 4:24 PM Subject: error-page directive I am using Tomcat 4.1.24 in Windows XP and I cannot define an error page. I have defined it in web.xml as error-page error-code500/error-code location/errorpage.hmtl/location /error-page If this is a cut'n'paste job from your web.xml page then the problem is you have defined a .hmtl and not .html file. G. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: error-page directive
Howdy, You may also have to disable Show Friendly Error Pages (or something similar) in Internet Explorer's Internet Options pages. Yoav Shapira Millennium ChemInformatics -Original Message- From: Carlos Pereira [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2003 11:25 AM To: [EMAIL PROTECTED] Subject: error-page directive I am using Tomcat 4.1.24 in Windows XP and I cannot define an error page. I have defined it in web.xml as error-page error-code500/error-code location/errorpage.hmtl/location /error-page and none of them works. The page displayed is Tomcat's default error page. The error-page tag seems to be simply ignored, as no errors are found in the application initialization. If I use error-page exception-typejava.lang.Throwable/exception-type location/errorpage.html/location /error-page and throw an exception, like RuntimeException, IE shows it's default Error 500 - Internal Server Error page. I tried to put errorpage.html both in the server's root and the application's context root. It doesn't work. I tried switching the location for a servlet mapping, like /error. It doesn´t work. I upgraded Tomcat to 5.0.12. The result is the same. So, what's the problem? Regards, Carlos Pereira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: error-page directive
Howdy, You may also have to disable Show Friendly Error Pages (or something similar) in Internet Explorer's Internet Options pages. (Yoav Shapira) Thanks. That worked fine, with both error-code and exception-type. It is not the best solution, though... users have to change their configuration. Isn't there another workaround? If this is a cut'n'paste job from your web.xml page then the problem is you have defined a .hmtl and not .html file. (Graham Reeds) No, it wasn't cut'n'paste. Sorry about that... Regards, Carlos Pereira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: error-page directive
Howdy, You may also have to disable Show Friendly Error Pages (or something similar) in Internet Explorer's Internet Options pages. (Yoav Shapira) Thanks. That worked fine, with both error-code and exception-type. It is not the best solution, though... users have to change their configuration. Isn't there another workaround? Possibly yes if you're running on an intranet: get your network admin to remotely update the IE options. They may not agree though ;) And I would understand them. Instead of worrying so much about the appearance of your custom error pages, try to code your app not to get as many errors ;) Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: error-page directive
Instead of worrying so much about the appearance of your custom error pages, try to code your app not to get as many errors ;) (Yoav Shapira) Nice one there :) I do, but i wanted to make sure no error message with stack traces is sent to the user. And I use RuntimeExceptions for those impossible situations, which end up happening. Thanks again, Carlos Pereira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Error-page directive does nothing
Hi, we have a lot of occasions where I use the directive error-page error-code500/error-code location/errorPages/500x.jsp/location /error-page in a web.xml file but it does nothing, particularly for errors thrown by a servlet. I have upgraded now to Tomcat 4.1.27 as I have seen some problems with this before but does anyone have any ideas? cheers Pete
error-page directive has no effect
Hi, ive got a problem currently with the error-page directive doing nothing when I use it in an app (on either tomcat 4.1.18 or .27). At the bottom of my app's web.xml, I have the following tag: error-page error-code500/error-code location/errorPages/500x.jsp/location /error-page This corresponds to a working page, however this tag is completely ignored. As a result, in order to get any 500 errors to be handled properly, I have to put an @page errorPage directive in the top of every JSP - this doesnt of course work for servlets, so presents a problem then. Has anyone any idea why it wouldnt work? I have had this problem thinking about it before which meant that any Struts actions would not get handled by the error handler. I ended up having to write a filter which caught them for me and forwarded the request to the error page with the exception held as a request attribute - this is obviously far from ideal!! thanks Pete Kiss Technologies http://www.kisstechnologies.co.uk/ 4, Percy Street London W1T 1DF Phone numbers: Phone 020 7692 9922 Fax 020 7692 9923
error when start tomcat if in the web.xml is the error-page directive
if in my web.xml i have this: error-page error-code404/error-code location/error.jsp/location /error-page the tomcat starts well but appears the next error. Can you help me to resolv it? thanks. ERROR: 13-dic-2002 13:19:14 org.apache.commons.digester.Digester error GRAVE: Parse Error at line 723 column 11: The content of element type web-app must match (icon?,display-name?,description?,distributable?,context-param*,filter*,fil ter-mapping*,listener*,servlet*,servlet-mapping*,session-config?,mime-mappin g*,welcome-file-list?,error-page*,taglib*,resource-env-ref*,resource-ref*,se curity-constraint*,login-config?,security-role*,env-entry*,ejb-ref*,ejb-loca l-ref*). org.xml.sax.SAXParseException: The content of element type web-app must match (icon?,display-name?,description?,distributable?,context-param*,filter*,fil ter-mapping*,listener*,servlet*,servlet-mapping*,session-config?,mime-mappin g*,welcome-file-list?,error-page*,taglib*,resource-env-ref*,resource-ref*,se curity-constraint*,login-config?,security-role*,env-entry*,ejb-ref*,ejb-loca l-ref*). at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(ErrorHand lerWrapper.java:232) at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:17 3) at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:36 2) at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:29 6) at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator. java:1953) at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:8 78) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.handleEndElement(XMLDo cumentFragmentScannerImpl.java:1144) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocu mentFragmentScannerImpl.java:987) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatc her.dispatch(XMLDocumentFragmentScannerImpl.java:1445) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocume ntFragmentScannerImpl.java:333) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:524) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:116 9) at org.apache.commons.digester.Digester.parse(Digester.java:1495) at org.apache.catalina.startup.ContextConfig.applicationConfig(ContextConfig.ja va:282) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:639) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java: 243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor t.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) 13-dic-2002 13:19:15 org.apache.jk.common.ChannelSocket init -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: error when start tomcat if in the web.xml is the error-page directive
Make sure that error-page element appears after welcome-file-list and before taglib. The order of the elements in any XML file is very important. HTH, Uri On Friday 13 December 2002 14:22, Dionisio Ruiz de Zarate wrote: if in my web.xml i have this: error-page error-code404/error-code location/error.jsp/location /error-page the tomcat starts well but appears the next error. Can you help me to resolv it? thanks. ERROR: 13-dic-2002 13:19:14 org.apache.commons.digester.Digester error GRAVE: Parse Error at line 723 column 11: The content of element type web-app must match (icon?,display-name?,description?,distributable?,context-param*,filter*,fi l ter-mapping*,listener*,servlet*,servlet-mapping*,session-config?,mime-mappi n g*,welcome-file-list?,error-page*,taglib*,resource-env-ref*,resource-ref*,s e curity-constraint*,login-config?,security-role*,env-entry*,ejb-ref*,ejb-loc a l-ref*). org.xml.sax.SAXParseException: The content of element type web-app must match (icon?,display-name?,description?,distributable?,context-param*,filter*,fi l ter-mapping*,listener*,servlet*,servlet-mapping*,session-config?,mime-mappi n g*,welcome-file-list?,error-page*,taglib*,resource-env-ref*,resource-ref*,s e curity-constraint*,login-config?,security-role*,env-entry*,ejb-ref*,ejb-loc a l-ref*). at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(ErrorHan d lerWrapper.java:232) at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:1 7 3) at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:3 6 2) at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:2 9 6) at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator . java:1953) at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java: 8 78) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.handleEndElement(XMLD o cumentFragmentScannerImpl.java:1144) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDoc u mentFragmentScannerImpl.java:987) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispat c her.dispatch(XMLDocumentFragmentScannerImpl.java:1445) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocum e ntFragmentScannerImpl.java:333) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:524) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:11 6 9) at org.apache.commons.digester.Digester.parse(Digester.java:1495) at org.apache.catalina.startup.ContextConfig.applicationConfig(ContextConfig.j a va:282) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:639) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java : 243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppo r t.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) 13-dic-2002 13:19:15 org.apache.jk.common.ChannelSocket init -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Uri Shohet mailto:[EMAIL PROTECTED] AMS Advanced Maintenance Systems Ltd. Science Based Industry Campus POB 23838, Jerusalem 91237, Israel Tel.: +972-2-541-7449 Cell: +972-54-259-850 Fax.: +972-2-581-4448 US Toll-Free: 1-866-389-2001 Registered Linux User #166615 (http://counter.li.org) -- To unsubscribe, e-mail:
RE: error when start tomcat if in the web.xml is the error-page directive
Dionisio, I do not find anything wrong with that entry in your web.xml file. The error is probably caused by another element.I have used error pages in my web-xml files with the same entry as yours without problems. Pedro -Mensaje original- De: Dionisio Ruiz de Zarate [mailto:[EMAIL PROTECTED]] Enviado el: viernes, 13 de diciembre de 2002 13:22 Para: [EMAIL PROTECTED] Asunto: error when start tomcat if in the web.xml is the error-page directive if in my web.xml i have this: error-page error-code404/error-code location/error.jsp/location /error-page the tomcat starts well but appears the next error. Can you help me to resolv it? thanks. ERROR: 13-dic-2002 13:19:14 org.apache.commons.digester.Digester error GRAVE: Parse Error at line 723 column 11: The content of element type web-app must match (icon?,display-name?,description?,distributable?,context-param*,filter*,fil ter-mapping*,listener*,servlet*,servlet-mapping*,session-config?,mime-mappin g*,welcome-file-list?,error-page*,taglib*,resource-env-ref*,resource-ref*,se curity-constraint*,login-config?,security-role*,env-entry*,ejb-ref*,ejb-loca l-ref*). org.xml.sax.SAXParseException: The content of element type web-app must match (icon?,display-name?,description?,distributable?,context-param*,filter*,fil ter-mapping*,listener*,servlet*,servlet-mapping*,session-config?,mime-mappin g*,welcome-file-list?,error-page*,taglib*,resource-env-ref*,resource-ref*,se curity-constraint*,login-config?,security-role*,env-entry*,ejb-ref*,ejb-loca l-ref*). at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(ErrorHand lerWrapper.java:232) at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:17 3) at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:36 2) at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:29 6) at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator. java:1953) at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:8 78) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.handleEndElement(XMLDo cumentFragmentScannerImpl.java:1144) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocu mentFragmentScannerImpl.java:987) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatc her.dispatch(XMLDocumentFragmentScannerImpl.java:1445) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocume ntFragmentScannerImpl.java:333) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:524) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:116 9) at org.apache.commons.digester.Digester.parse(Digester.java:1495) at org.apache.catalina.startup.ContextConfig.applicationConfig(ContextConfig.ja va:282) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:639) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java: 243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor t.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) 13-dic-2002 13:19:15 org.apache.jk.common.ChannelSocket init -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: error when start tomcat if in the web.xml is the error-page directive
Verify the order of your elements in the web.xml file. -Mensaje original- De: Dionisio Ruiz de Zarate [mailto:[EMAIL PROTECTED]] Enviado el: viernes, 13 de diciembre de 2002 13:22 Para: [EMAIL PROTECTED] Asunto: error when start tomcat if in the web.xml is the error-page directive if in my web.xml i have this: error-page error-code404/error-code location/error.jsp/location /error-page the tomcat starts well but appears the next error. Can you help me to resolv it? thanks. ERROR: 13-dic-2002 13:19:14 org.apache.commons.digester.Digester error GRAVE: Parse Error at line 723 column 11: The content of element type web-app must match (icon?,display-name?,description?,distributable?,context-param*,filter*,fil ter-mapping*,listener*,servlet*,servlet-mapping*,session-config?,mime-mappin g*,welcome-file-list?,error-page*,taglib*,resource-env-ref*,resource-ref*,se curity-constraint*,login-config?,security-role*,env-entry*,ejb-ref*,ejb-loca l-ref*). org.xml.sax.SAXParseException: The content of element type web-app must match (icon?,display-name?,description?,distributable?,context-param*,filter*,fil ter-mapping*,listener*,servlet*,servlet-mapping*,session-config?,mime-mappin g*,welcome-file-list?,error-page*,taglib*,resource-env-ref*,resource-ref*,se curity-constraint*,login-config?,security-role*,env-entry*,ejb-ref*,ejb-loca l-ref*). at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(ErrorHand lerWrapper.java:232) at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:17 3) at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:36 2) at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:29 6) at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator. java:1953) at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:8 78) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.handleEndElement(XMLDo cumentFragmentScannerImpl.java:1144) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocu mentFragmentScannerImpl.java:987) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatc her.dispatch(XMLDocumentFragmentScannerImpl.java:1445) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocume ntFragmentScannerImpl.java:333) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:524) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:116 9) at org.apache.commons.digester.Digester.parse(Digester.java:1495) at org.apache.catalina.startup.ContextConfig.applicationConfig(ContextConfig.ja va:282) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:639) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java: 243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor t.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) 13-dic-2002 13:19:15 org.apache.jk.common.ChannelSocket init -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
error-page directive does not catch HTTP STATUS 500 errors!
Hi all, I am using a tomcat 4.0.1 standalone running on Unix. I configured my web.xml like the following: error-page exception-typejava.lang.Throwable/exception-type location/errors/err-except.html/location /error-page error-page error-code500/error-code location/errors/err-code500.html/location /error-page error-page error-code404/error-code location/errors/err-code404.html/location /error-page the code should catch all error codes - but unfortunately it does not. On HTTP STATUS 500 errors a page cannot be displayed appears. I crawled the web for this issue but i did not find anything about it. In my WEB-INF/web.xml i created the following constraint in order to generate a HTTP STATUS 500 error. security-constraint web-resource-collection web-resource-nameno-access/web-resource-name url-pattern/test.html/url-pattern /web-resource-collection auth-constraint role-namenobody/role-name /auth-constraint /security-constraint Did anyone already have found a solution? cheers// moritz smime.p7s Description: S/MIME Cryptographic Signature
error-page directive throw a java.lang.StackOverflowError
Hello, I'm using Tomcat 3.2.1 under Windows 2000. In my web.xml descriptor, I've set up this error-page directive error-page error-code404/error-code location/404.html/location /error-page 404.html is a the root of my context. When I type an incorrect URL, I've got a 500 response, and a java.lang.StackOverflowError exception in thrown. Any idea ??? In the log I've got: Plenty of these lines: 2001-04-12 10:56:12 - Ctx( /glextra ): Get real path /404.html C:\tomcat321\webapps\glextra\404.html C:\tomcat321\webapps\glextra 2001-04-12 10:56:12 - Ctx( /glextra ): Get real path /default.jsp2 C:\tomcat321\webapps\glextra\default.jsp2 C:\tomcat321\webapps\glextra Than: 2001-04-12 10:56:12 - Ctx( /glextra ): Exception in: R( /glextra + /default.jsp2 + null) - java.lang.StackOverflowError at java.lang.Exception.init(Exception.java:38) at java.io.IOException.init(IOException.java:43) at java.io.FileNotFoundException.init(FileNotFoundException.java:62) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:64) at java.io.FileInputStream.init(FileInputStream.java:95) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:365) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service
RE: error-page directive throw a java.lang.StackOverflowError
Hi, I am using Tomcat 3.2.1 under RedHat Linux and also tried to configure my own error-page entries in the WEB.XML of the context in question. And it failed with a similar error (stack overflow) flodding my console with lines like Ctx( ): 404 R( + /nono.xml + null ) null I set Cocoon's Tomcat context to "/" making my Apache and Cocoon conext pointing to .../htdocs directory. So far so good. Only too bad, that ERROR 404 (and others are not handled properly). BTW: if I use the Tomcat context "/cocoon" things are *no* better regarding error-page behaviour! Does any of you know where I do wrong? Regards, Arne -Original Message- From: Stphane BAUDET [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 12, 2001 11:45 AM To: [EMAIL PROTECTED] Subject: error-page directive throw a java.lang.StackOverflowError Hello, I'm using Tomcat 3.2.1 under Windows 2000. In my web.xml descriptor, I've set up this error-page directive error-page error-code404/error-code location/404.html/location /error-page 404.html is a the root of my context. When I type an incorrect URL, I've got a 500 response, and a java.lang.StackOverflowError exception in thrown. Any idea ??? In the log I've got: Plenty of these lines: 2001-04-12 10:56:12 - Ctx( /glextra ): Get real path /404.html C:\tomcat321\webapps\glextra\404.html C:\tomcat321\webapps\glextra 2001-04-12 10:56:12 - Ctx( /glextra ): Get real path /default.jsp2 C:\tomcat321\webapps\glextra\default.jsp2 C:\tomcat321\webapps\glextra Than: 2001-04-12 10:56:12 - Ctx( /glextra ): Exception in: R( /glextra + /default.jsp2 + null) - java.lang.StackOverflowError at java.lang.Exception.init(Exception.java:38) at java.io.IOException.init(IOException.java:43) at java.io.FileNotFoundException.init(FileNotFoundException.java:62) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:64) at java.io.FileInputStream.init(FileInputStream.java:95) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:365) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(Contex
RE: error-page directive throw a java.lang.StackOverflowError
Generally, getting a stack overflow in this situation indicates that your error page has an error, which is handled by your error page, which has an error I would suggest removing the error page directive and then making a request for the error page. Once its working then add the error page directive back. This way you first verify that the error page works, and then you verify that the errorpage directive is set up correctly. Randy -Original Message- From: Arne Borkowski (borko.net) [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 12, 2001 8:40 AM To: [EMAIL PROTECTED] Subject: RE: error-page directive throw a java.lang.StackOverflowError Hi, I am using Tomcat 3.2.1 under RedHat Linux and also tried to configure my own error-page entries in the WEB.XML of the context in question. And it failed with a similar error (stack overflow) flodding my console with lines like Ctx( ): 404 R( + /nono.xml + null ) null I set Cocoon's Tomcat context to "/" making my Apache and Cocoon conext pointing to .../htdocs directory. So far so good. Only too bad, that ERROR 404 (and others are not handled properly). BTW: if I use the Tomcat context "/cocoon" things are *no* better regarding error-page behaviour! Does any of you know where I do wrong? Regards, Arne -Original Message- From: Stphane BAUDET [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 12, 2001 11:45 AM To: [EMAIL PROTECTED] Subject: error-page directive throw a java.lang.StackOverflowError Hello, I'm using Tomcat 3.2.1 under Windows 2000. In my web.xml descriptor, I've set up this error-page directive error-page error-code404/error-code location/404.html/location /error-page 404.html is a the root of my context. When I type an incorrect URL, I've got a 500 response, and a java.lang.StackOverflowError exception in thrown. Any idea ??? In the log I've got: Plenty of these lines: 2001-04-12 10:56:12 - Ctx( /glextra ): Get real path /404.html C:\tomcat321\webapps\glextra\404.html C:\tomcat321\webapps\glextra 2001-04-12 10:56:12 - Ctx( /glextra ): Get real path /default.jsp2 C:\tomcat321\webapps\glextra\default.jsp2 C:\tomcat321\webapps\glextra Than: 2001-04-12 10:56:12 - Ctx( /glextra ): Exception in: R( /glextra + /default.jsp2 + null) - java.lang.StackOverflowError at java.lang.Exception.init(Exception.java:38) at java.io.IOException.init(IOException.java:43) at java.io.FileNotFoundException.init(FileNotFoundException.java:62) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:64) at java.io.FileInputStream.init(FileInputStream.java:95) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:365) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.Se
RE: error-page directive throw a java.lang.StackOverflowError
Hi I had a similar problem my self... Here is how i solvedit: I renamed the 404.jsp to something else... like badrequest.jsp or something... (not sure if requeired) And make sure to add this to your error page ! :%@ page isErrorPage="true" % Hades -Original Message- From: Arne Borkowski (borko.net) [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 12, 2001 3:40 PM To: [EMAIL PROTECTED] Subject: RE: error-page directive throw a java.lang.StackOverflowError Hi, I am using Tomcat 3.2.1 under RedHat Linux and also tried to configure my own error-page entries in the WEB.XML of the context in question. And it failed with a similar error (stack overflow) flodding my console with lines like Ctx( ): 404 R( + /nono.xml + null ) null I set Cocoon's Tomcat context to "/" making my Apache and Cocoon conext pointing to .../htdocs directory. So far so good. Only too bad, that ERROR 404 (and others are not handled properly). BTW: if I use the Tomcat context "/cocoon" things are *no* better regarding error-page behaviour! Does any of you know where I do wrong? Regards, Arne -Original Message- From: Stphane BAUDET [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 12, 2001 11:45 AM To: [EMAIL PROTECTED] Subject: error-page directive throw a java.lang.StackOverflowError Hello, I'm using Tomcat 3.2.1 under Windows 2000. In my web.xml descriptor, I've set up this error-page directive error-page error-code404/error-code location/404.html/location /error-page 404.html is a the root of my context. When I type an incorrect URL, I've got a 500 response, and a java.lang.StackOverflowError exception in thrown. Any idea ??? In the log I've got: Plenty of these lines: 2001-04-12 10:56:12 - Ctx( /glextra ): Get real path /404.html C:\tomcat321\webapps\glextra\404.html C:\tomcat321\webapps\glextra 2001-04-12 10:56:12 - Ctx( /glextra ): Get real path /default.jsp2 C:\tomcat321\webapps\glextra\default.jsp2 C:\tomcat321\webapps\glextra Than: 2001-04-12 10:56:12 - Ctx( /glextra ): Exception in: R( /glextra + /default.jsp2 + null) - java.lang.StackOverflowError at java.lang.Exception.init(Exception.java:38) at java.io.IOException.init(IOException.java:43) at java.io.FileNotFoundException.init(FileNotFoundException.java:62) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:64) at java.io.FileInputStream.init(FileInputStream.java:95) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:365) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager. java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor. java:387) at org.apache.tomcat.core.Ha
RE: error-page directive throw a java.lang.StackOverflowError
Hi, everything is fine again, after I deleted the contents of the /usr/local/tomcat/work directory. Could someone explain to me, how the contents of this directory affects a rebooted server? And I "shutdown -r now" the Linux box. I am really new to Tomcat, so maybe this question is not too stupid at all? -Arne
RE: error-page directive throw a java.lang.StackOverflowError
The Work directory is where the compiled JSPs go. When tomcat receives a request for a new JSP it checks the timestamp of the JSP file against the timestamp of the compiled file and uses the newer. Since you don't want to compile files every time the server (tomcat process) restarts, the files persist across startup/shutdown. Randy -Original Message- From: Arne Borkowski (borko.net) [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 12, 2001 10:55 AM To: [EMAIL PROTECTED] Subject: RE: error-page directive throw a java.lang.StackOverflowError Hi, everything is fine again, after I deleted the contents of the /usr/local/tomcat/work directory. Could someone explain to me, how the contents of this directory affects a rebooted server? And I "shutdown -r now" the Linux box. I am really new to Tomcat, so maybe this question is not too stupid at all? -Arne
