yeh...we need the apache url re-writting stuff in a servlet. That's an issue with orion. I think the opensymphony people are writing something.
There is a simple workaround. Have a forward.jsp as your welcome page for the default app. In the forward.jsp, use this code:
<%     String servletPath = request.getRequestURI().substring(0, request.getRequestURI().indexOf(request.getServletPath()));
    response.sendRedirect(servletPath+"/somepath/to/index or home or whatever.html") ;
the somepath can be /main/home.html, for example.
in your web.xml, map your "controller-rewriter servlet"  to the /main/*
so instead of your pages asking for resouces at /myfavoritegif.gif, they would just be /main/myfavoritegif.gif.
This is ugly, and quick and dirty, but it works. You can even read in an xml file when you rewriter servlet starts up so that all of your path mapping, rewritting works like apache.
The elephantwalker
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Winspur
Sent: Thursday, May 10, 2001 8:51 AM
To: Orion-Interest
Subject: Servlet Mapping Recursion Problem

In my web.xml I set up the servlet mapping, for a (front) servlet to handle all requests for the web app, to '/'. This works to the extent that all requests are passed to the servlet. BUT... if I do a forward to another resource from the servlet, the servlet's doGet() method is invoked recursively with no response generated until the jvm runs out of memory. The same thing happens with a url-pattern of '/*'. If the servlet itself generates html output, that works.  If I map my servlet to a specific resource, like /index.html, forwarding works fine, but the servlet cant handle all requests and 'http://myhost/myapp' returns 'no directory browsing'. 

The url-pattern '/' seems like a valid directory specification (as per the servlet 2.2 spec, 'Servlet Mapping Techniques') and a front component, handling all requests is fundamental in the j2EE blueprints (, section 10.6), so my approach seems architecturally reasonable.

I've looked thru the archives and found two reports of the same problem. A proposed workaround from Magnus seems to recommend explicitly mapping every request your app generates (which would make the web.xml coding difficult to maintain in a large app) pendng the delivery of 'filters', perhaps in Servlet 2.3. I dont really understand what Magnus is suggesting:

PS: If you're bound to 2.2 or lower then you will not be able to use Filters, in that case you'd have to apply a more complex solution with duplicate resource roots and so on.

It looks like 'no front servlets on Orion' to me, but I hope I'm wrong.

I was not able to find any references to the problem on bugzilla, but I'm not very adept with its query interface.

My hunch is that Orion's request dispatcher is invoked in two contexts (from a client, and from a forward) and does not distinguish between them when it comes to selecting a resource to respond to the client. If the dispatcher ignored mapping in the forward context and just accepted the specified resource, the recursion problem would vanish and the front servlet would trap ALL client requests as per the blueprint architecture. Just a hunch, things are probably not that simple.

Does anyone know if this is a problem with other webservers ? My experience with Apache was all static pages.

My environment is NT4(sp6), Orion 1.4.8, IE 5.00, JDK 1.2.2.

Also, if somebody is actually using the front servlet pattern and univeral mapping on Orion, and could let me know how to set it up and/or get around the recursion I'd be a happy camper.



Reply via email to