RE: [Qexo-general] useful servlet

[Tom Reilly]

Apparently tomcat's getNamedDispatcher doesn't resolve pure servlet
class names.  Admittedly it isn't something required by the servlet 
spec.

getRequestDispatcher with "/servlet/" + page_basename should be more
portable.  Although an implicit /servlet mapping isn't required by the 
spec either.

> -----Original Message-----
> From: Per Bothner [mailto:address@hidden 
> Sent: Wednesday, January 29, 2003 2:31 AM
> To: Tom Reilly
> Cc: 'address@hidden'
> Subject: Re: [Qexo-general] useful servlet
> 
> 
> Tom Reilly wrote:
> > Useful servlet for automating the compilation process with 
> a simple caching mechanism
> > (so the page isn't compiled everytime).   Makes .xql, .scm 
> files work simliar to jsp.
> 
> I didn't work for me.  I'm using Tomcat 4.0.  When I try:
> http://localhost:8080/qexo2/test.xql
> I get:
> 
> A Servlet Exception Has Occurred
> 
> java.lang.NullPointerException
>       at 
> gnu.kawa.servlet.KawaPageServlet.doGet(KawaPageServlet.java:68)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>       at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> er(Unknown 
> Source)
> etc
> 
> I added a log command (line 68 is the rd.forward call):
>          RequestDispatcher rd = 
> context.getNamedDispatcher(servletName);
>       log("servlet-path: "+sp+" servletName: "+servletName+" 
> rd: "+rd+" 
> context: "+context);
>          rd.forward(request, response);
> 
> The log file localhost_log.2003-01-28.txt contains:
> 2003-01-28 23:08:43 KawaPageServlet: servlet-path:
> /test.xql servletName: test rd: null context: 
> address@hidden
> So the context.getNamedDispatcher is failing.  Tomcat is
> finding the correct .xql file, because when I "mis-type" the
> URL or add a syntax error to the .xql file I get reasonable
> errors messages.
> 
> > I couldn't figure out how to make different language files 
> work at the same time (ie 
> > in the same VM).  After one invocation Kawa's internals 
> seems hardwired to the first 
> > language.  
> 
> Yes, there are probably a number of little places in Kawa that should
> be fixed to make this work, starting with the static fields
> Interpreter.defaultInterpreter and Environment.global.
> -- 
>       --Per Bothner
> address@hidden   http://www.bothner.com/per/
>