Googles suggested implementation is GPL, which prohibits me from using it, and I'm not paying for the equivalent of mod_rewrite for tomcat. I'd rather write my own and publish it under a less restrictive license.
Regards my questions, (1) still stands, (2) I've partially answered for myself, by looking in the servlet 2.4 JSR (notably the <dispatcher>*</dispatcher> web.xml option seems to be missing from the Tomcat docs pages), and RequestDispatcher.forward()/include() does seem to work as expected inside a Filter. (3) I guess I'll try to reproduce this and submit an appropriately carefully worded bug after trawling through the specs myself instead of asking on the mailing list, and having someone read the first two lines and decide that I haven't even tried to use google. On 2/10/06, Bruno Georges <[EMAIL PROTECTED]> wrote: > > Hi Antony > Such implementation already exist. > Google is your friend there. > > Bruno Georges > > Glencore International AG > Tel. +41 41 709 3204 > Fax +41 41 709 3000 > > > ----- Original Message ----- > From: Antony Riley [EMAIL PROTECTED] > Sent: 10.02.2006 14:32 > To: users@tomcat.apache.org > Subject: pure java mod_rewrite using javax.servlet.Filter > > Hiya all, > > I'm looking at writing a Filter class which does request rewriting similar > to mod_rewrite in a apache for Tomcat (preferably written so that it will > work with any servlets 2.4 compliant server). > > I'm having a little trouble with regards how filters actually work. > > The following all happen inside filters (tomcat 5.5, latest stable > release): > > 1) Wrapping the HttpServletRequest with one which modifies > request.getRequestURI(), request.getPathInfo() request.getServletPath() > does > not seem to work, as at this point tomcat seems to have already decided > what > server will proces the request. > > 2) using request.getRequestDispatcher(<path>).forward(request,response) > seems to work, however, this does not cause the Filter to be reapplied as > I > would have expected if called at this stage in the request parsing > process. > > 3) When declaring a filter in a web.xml for an application with a > url-mapping of /* seems to break hideously if there is also a default > servlet also declared in the web.xml (the application specific web.xml, > not > the server web.xml) [I can and will probably will have to provide further > info on this] seems to break rather horribly causing tomcat to server up > unprocessed jsp pages, and fail to do directory indexes, even though > without > the filter mapping it works correctly. > > -Antony Riley > > > LEGAL DISCLAIMER. The contents of this e-mail and any attachments are > strictly > confidential and they may not be used or disclosed by someone who is not a > named recipient. > If you have received this email in error please notify the sender by > replying > to this email inserting the word "misdirected" as the message and delete > this > e-mail from your system. > > >
