You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Marcus Crafter <cr...@fztig938.bank.dresdner.net> on 2001/08/23 18:34:27 UTC
class xxx is not a servlet ?
Hi All,
Hope all is well.
Just tried to see how our applications works with TC4B7. We're getting
the following exception in our log file, telling us that our servlet
class is not a servlet:
2001-08-23 18:24:31 StandardContext[/diva-fs2]: Servlet /diva-fs2 threw load() exception
javax.servlet.ServletException: Class dreba.prj.fs2.fdn.portal.Portal is not a S
ervlet
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:81
3)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContex
t.java:3240)
.... <cut> ....
----- Root Cause -----
java.lang.ClassCastException: dreba.prj.fs2.fdn.portal.Portal
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:80
9)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContex
t.java:3240)
Portal class derives from CocoonServlet, which derives in turn from
HttpServlet. I've compiled our application with the servlet.jar from
TC4B7, but I still get the same exception. The application
works fine with TC323.
Any ideas what this could be ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
Re: custom error page not working in TC40-b7
Posted by "Craig R. McClanahan" <cr...@apache.org>.
See intermixed.
On Thu, 23 Aug 2001, Peiqiang Han wrote:
> Date: Thu, 23 Aug 2001 19:52:11 +0500
> From: Peiqiang Han <pe...@videotron.ca>
> Reply-To: tomcat-user@jakarta.apache.org
> To: tomcat-user@jakarta.apache.org
> Subject: custom error page not working in TC40-b7
>
> > I have some problems to make custome error pages working. I have
> done my test with TC40-b7 > on Linux Redhat 7.1 Kernel 2.4.2.
>
> 1) The servlet ErrorHandlingServlet.java is in
> $CATALINA_HOME/webapps/test/WEB-INF/classes:
>
> import javax.servlet.*;
> import javax.servlet.http.*;
> import java.io.IOException;
>
> public class ErrorHandlingServlet extends HttpServlet {
>
> public void doGet(HttpServletRequest req, HttpServletResponse res)
> throws ServletException, IOException {
>
> String param = req.getParameter("code");
>
> if(param.equals("Servlet"))
> throw new ServletException("ServletException thrown!!!");
> else if(param.equals("Unavailable"))
> throw new UnavailableException("UnavailableException");
> else
> res.sendError(404, "404 is returned");
> }
>
> }
>
> 2) The custom error pages are in
> $CATALINA_HOME/webapps/test/jsp/errorpage, an example is
> errorpage.jsp:
>
> <%@ page isErrorPage="true" %>
>
> <html>
> <body bgcolor="red">
>
> <h1> The exception msg is <%= exception.getMessage() %> </h1>
> </body>
> </html>
>
Note that the "exception" variable will be set correctly only if the error
happened on a JSP page that used:
<%@ page errorPage="/errorpage.jsp" %>
at the top.
For exceptions thrown by a servlet, the details of the exception are
passed as request attributes that you can access from within the error
displaying page, as outlined in Section 9.9 of the Servlet 2.3 PFD2 spec
<http://java.sun.com/products/servlet/download.html>.
In particular, the actual exception thrown is passed under request
attribute "javax.servlet.error.exception" (of type Throwable).
> 3) The Deployment descriptor
> $CATALINA_HOME/webapps/test/WEB-INF/web.xml is configured as follow:
>
> <servlet>
> <servlet-name>errorHandling</servlet-name>
> <servlet-class>ErrorHandlingServlet</servlet-class>
> </servlet>
>
> <servlet-mapping>
> <servlet-name>errorHandling</servlet-name>
> <url-pattern>/eHandling</url-pattern>
> </servlet-mapping>
> ...
>
> <error-page>
> <exception-type>javax.servlet.ServletException</exception-type>
> <location>/jsp/errorpage/errorpage.jsp</location>
> </error-page>
> <error-page>
> <exception-type>java.lang.NullPointerException</exception-type>
> <location>/jsp/errorpage/errorpageUn.jsp</location>
> </error-page>
> <error-page>
> <error-code>404</error-code>
> <location>/jsp/errorpage/errorpage404.jsp</location>
> </error-page>
>
> When I accessed the ErrorHandlingServlet with the URL:
> http://localhost:8080/test/servlet/ErrorHandlingServlet?code=Servlet,
> I expected the TC to return the custom error page
> /jsp/errorpage/errorpage.jsp. But it was the following page returned:
>
> A Servlet Exception Has Occurred
>
> javax.servlet.ServletException: ServletException thrown!!!
> at ErrorHandlingServlet.doGet(ErrorHandlingServlet.java:13)
> 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)
> ...
>
I will look at this ... it should have gone to your errorpage.jsp page,
which would itself have thrown a null pointer exception (because
"exception" would not have been set). And error pages seem to work for
all of my unit test cases ...
> It is interesting to note that when I put the error-page tags just
> bellow the taglib tag, as specified by the DTD, there was the
> following error message in the localhost_log.txt when TC was
> startedup:
>
> 2001-08-23 19:48:47 ContextConfig[/test] Parse error in application web.xml
> org.xml.sax.SAXParseException: Element "web-app" does not allow "error-page" here.
> at org.apache.crimson.parser.Parser2.error(Parser2.java:3013)
> at
> org.apache.crimson.parser.ValidatingParser$ChildrenValidator.consume(ValidatingParser.java:349)
>
> at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1303)
> ...
>
> So I have had to put error-page tags before the taglib tag, but the custom error page could
> still not be shown. Have I missed somethings?
According to the DTD I am looking at (in the PFD2 spec), <error-page> has
to come *before* <taglib> tags, not *after*.
>
>
> Regards
> Peiqiang Han
>
>
>
Craig McClanahan
custom error page not working in TC40-b7
Posted by Peiqiang Han <pe...@videotron.ca>.
> I have some problems to make custome error pages working. I have done my test with TC40-b7
> on Linux Redhat 7.1 Kernel 2.4.2.
1) The servlet ErrorHandlingServlet.java is in $CATALINA_HOME/webapps/test/WEB-INF/classes:
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.IOException;
public class ErrorHandlingServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
String param = req.getParameter("code");
if(param.equals("Servlet"))
throw new ServletException("ServletException thrown!!!");
else if(param.equals("Unavailable"))
throw new UnavailableException("UnavailableException");
else
res.sendError(404, "404 is returned");
}
}
2) The custom error pages are in $CATALINA_HOME/webapps/test/jsp/errorpage, an example is
errorpage.jsp:
<%@ page isErrorPage="true" %>
<html>
<body bgcolor="red">
<h1> The exception msg is <%= exception.getMessage() %> </h1>
</body>
</html>
3) The Deployment descriptor $CATALINA_HOME/webapps/test/WEB-INF/web.xml is configured as
follow:
<servlet>
<servlet-name>errorHandling</servlet-name>
<servlet-class>ErrorHandlingServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>errorHandling</servlet-name>
<url-pattern>/eHandling</url-pattern>
</servlet-mapping>
...
<error-page>
<exception-type>javax.servlet.ServletException</exception-type>
<location>/jsp/errorpage/errorpage.jsp</location>
</error-page>
<error-page>
<exception-type>java.lang.NullPointerException</exception-type>
<location>/jsp/errorpage/errorpageUn.jsp</location>
</error-page>
<error-page>
<error-code>404</error-code>
<location>/jsp/errorpage/errorpage404.jsp</location>
</error-page>
When I accessed the ErrorHandlingServlet with the URL:
http://localhost:8080/test/servlet/ErrorHandlingServlet?code=Servlet, I expected the TC to
return the custom error page /jsp/errorpage/errorpage.jsp. But it was the following page
returned:
A Servlet Exception Has Occurred
javax.servlet.ServletException: ServletException thrown!!!
at ErrorHandlingServlet.doGet(ErrorHandlingServlet.java:13)
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)
...
It is interesting to note that when I put the error-page tags just bellow the taglib tag, as
specified by the DTD, there was the following error message in the localhost_log.txt when TC
was startedup:
2001-08-23 19:48:47 ContextConfig[/test] Parse error in application web.xml
org.xml.sax.SAXParseException: Element "web-app" does not allow "error-page" here.
at org.apache.crimson.parser.Parser2.error(Parser2.java:3013)
at
org.apache.crimson.parser.ValidatingParser$ChildrenValidator.consume(ValidatingParser.java:349)
at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1303)
...
So I have had to put error-page tags before the taglib tag, but the custom error page could
still not be shown. Have I missed somethings?
Regards
Peiqiang Han
Re: class xxx is not a servlet ?
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Craig,
Found it. After your pointer about class mixup's I checked our
libraries. Someone had sneaked in j2ee.jar which had a copy of the
javax.servlet.* classes. After I removed this it worked fine.
Cheers,
Marcus
On Thu, 23 Aug 2001, Marcus Crafter wrote:
> Hi Craig,
>
> Thanks for your fast reply! :-)
>
> On Thu, 23 Aug 2001, Craig R. McClanahan wrote:
>
> > 99.9% cause of this is having servlet.jar in the wrong place (it belongs
> > in $CATALINA_HOME/commons/lib *only*), having it in your Java extensions
> > directory ($JAVA_HOME/jre/lib/ext), or hacking it in to the CLASSPATH when
> > Tomcat is started.
> >
> > In particular, IIRC, Cocoon (at least for a while) was including a copy of
> > servlet.jar inside the webapp's /WEB-INF/lib directory. It should
> > absolutely *not* be there.
>
> I've checked this, it's not there. The servlet jar isn't included in
> our application's WEB-INF/lib directory, nor the cocoon sample
> application any more.
>
> The strange thing is that the cocoon sample application works fine, so
> it must be some config problem with our application. Kind of confused
> what it could be though. :-(
>
> I'll keep trying.
>
> Cheers,
>
> Marcus
>
>
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
Re: class xxx is not a servlet ?
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Craig,
Thanks for your fast reply! :-)
On Thu, 23 Aug 2001, Craig R. McClanahan wrote:
> 99.9% cause of this is having servlet.jar in the wrong place (it belongs
> in $CATALINA_HOME/commons/lib *only*), having it in your Java extensions
> directory ($JAVA_HOME/jre/lib/ext), or hacking it in to the CLASSPATH when
> Tomcat is started.
>
> In particular, IIRC, Cocoon (at least for a while) was including a copy of
> servlet.jar inside the webapp's /WEB-INF/lib directory. It should
> absolutely *not* be there.
I've checked this, it's not there. The servlet jar isn't included in
our application's WEB-INF/lib directory, nor the cocoon sample
application any more.
The strange thing is that the cocoon sample application works fine, so
it must be some config problem with our application. Kind of confused
what it could be though. :-(
I'll keep trying.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
Re: class xxx is not a servlet ?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
99.9% cause of this is having servlet.jar in the wrong place (it belongs
in $CATALINA_HOME/commons/lib *only*), having it in your Java extensions
directory ($JAVA_HOME/jre/lib/ext), or hacking it in to the CLASSPATH when
Tomcat is started.
In particular, IIRC, Cocoon (at least for a while) was including a copy of
servlet.jar inside the webapp's /WEB-INF/lib directory. It should
absolutely *not* be there.
Craig McClanahan
On Thu, 23 Aug 2001, Marcus Crafter wrote:
> Date: Thu, 23 Aug 2001 18:34:27 +0200 (CEST)
> From: Marcus Crafter <cr...@fztig938.bank.dresdner.net>
> Reply-To: tomcat-user@jakarta.apache.org
> To: Tomcat User Mailing List <to...@jakarta.apache.org>
> Subject: class xxx is not a servlet ?
>
> Hi All,
>
> Hope all is well.
>
> Just tried to see how our applications works with TC4B7. We're getting
> the following exception in our log file, telling us that our servlet
> class is not a servlet:
>
> 2001-08-23 18:24:31 StandardContext[/diva-fs2]: Servlet /diva-fs2 threw load() exception
> javax.servlet.ServletException: Class dreba.prj.fs2.fdn.portal.Portal is not a S
> ervlet
> at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:81
> 3)
> at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContex
> t.java:3240)
> .... <cut> ....
> ----- Root Cause -----
> java.lang.ClassCastException: dreba.prj.fs2.fdn.portal.Portal
> at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:80
> 9)
> at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContex
> t.java:3240)
>
> Portal class derives from CocoonServlet, which derives in turn from
> HttpServlet. I've compiled our application with the servlet.jar from
> TC4B7, but I still get the same exception. The application
> works fine with TC323.
>
> Any ideas what this could be ?
>
> Cheers,
>
> Marcus
>
>
> --
> .....
> ,,$$$$$$$$$, Marcus Crafter
> ;$' '$$$$: Computer Systems Engineer
> $: $$$$: Open Software Associates GmbH
> $ o_)$$$: 82-84 Mainzer Landstrasse
> ;$, _/\ &&:' 60327 Frankfurt Germany
> ' /( &&&
> \_&&&&' Email : Marcus.Crafter@osa.de
> &&&&. Business Hours : +49 69 9757 200
> &&&&&&&:
>
>