Thanks, > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of Craig R. McClanahan > Sent: Friday, October 26, 2001 1:58 AM > To: [EMAIL PROTECTED] > Subject: RE: Filters on error/index pages > > > > > On Thu, 25 Oct 2001, Deacon Marcus wrote: > > > Date: Thu, 25 Oct 2001 14:08:36 +0200 > > From: Deacon Marcus <[EMAIL PROTECTED]> > > Reply-To: [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > > Subject: RE: Filters on error/index pages > > > > Hi, > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > > > Behalf Of Craig R. McClanahan > > > Sent: Thursday, October 25, 2001 12:26 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Filters on error/index pages > > > > > > > > > > > > > > > On Wed, 24 Oct 2001, Deacon Marcus wrote: > > > > > > > Date: Wed, 24 Oct 2001 16:20:11 +0200 > > > > From: Deacon Marcus <[EMAIL PROTECTED]> > > > > Reply-To: [EMAIL PROTECTED] > > > > To: [EMAIL PROTECTED] > > > > Subject: Filters on error/index pages > > > > > > > > Hi, > > > > Are Filters applied to index (default in folder) or error > pages? I'm not > > > > 100% positive from the documentation. Sorry if it's basic or > > > obvious when > > > > looking at source, but I'm recovering from caffeine overdose > > > (my doc says > > > > half of what I took should be enough to kill me ;/ ) and have killer > > > > headaches so my iq and concentration ability are at 25% > normal, and my > > > > deadlines are near :( > > > > > > > > Thanks in advance, greetings, deacon Marcus > > > > > > > > > > > > > > The basic rule is that Filters are applied *only* on the originally > > > requested URL from the client. In practice, that means the following: > > > - Request to a servlet or JSP page - yes > > > - Static resources in the webapp - yes (*) > > > - RequestDispatcher.include() - no > > > - RequestDispatcher.forward() - no > > > > BTW, is there any way to simulate filtered RD.i and RD.f? That should be > > possible with a help of brigde servlet having access to Tomcat's > > configuration data, right? Could you give me some clues where to start? > > > > In order to do this transparently to the servlet that is using the > RequestDispatcher, you would have to actually modify Tomcat internals to > change the implementation object returned when the servlet calls > ServletContext.getRequestDispatcher() and > ServletContext.getNamedDispatcher(). As a starting point, you would be > wanting to subclass the following classes: > > * org.apache.catalina.core.StandardContext - The basic representation > of a web application. Modify the getServletContext() method to > return your subclass of ApplicationContext. > > * org.apache.catalina.core.ApplicationContext - Modify the implementation > of getRequestDispatcher() and getNamedDispatcher() to return your > subclass of ApplicationDispatcher. > > * org.apache.catalina.core.ApplicationDispatcher - Change the processing > in the invoke() method to construct a filter chain and use it. You > could use the code in StandardWrapperValve (which is used for the actual > requests) as a model. > > Of course, all of this would tie you now and forever more to this > architecture. I would suggest you consider architecting your application > to conform to the standard, rather than modifying your container to > conform to your architecture.
I know all pros and cons, I'm generally not aganist vendor-lock-in as long as it's not Microsoft or similar. I have nothing aganist vendor-lock-in when it comes to a high quality product which itself is portable. > > Is there any possibility for a webapp to get acces to Tomcat's > classes? From > > what I thought, it would be easy to do providing custom valve saving > > reference to it's context in ServletContext's attribute, but > maybe there's > > some more direct way? > > > > Classes loaded from the Catalina class loader are not visible to web > applications. Further, the webapp class loader disallows any attempt to > load an org.apache.catalina.* class from itself. So, even if you created > a Valve as you describe and created a servlet context attribute, the web > app would still throw a ClassNotFoundException when it tried to access the > attribute. That what I not like in multiple classloaders... So, basically if I want/need to write something which has its hands in Tomcat's guts I need to make it part of custom Tomcat compilation? What's the policy on distributing such modified versions as a part of a out-of-box-workable webapps etc? > The *only* way to have a servlet able to reference Catalina internal > classes is to make it an implementation of ContainerServlet (as the > servlets for the Manager and Invoker features are), and loaded from the > Catalina class loader (i.e. stored in server/classes or server/lib). > > > > - Error page - no > > > > That hurts. Any possible workaround? Where are error pages (I > need 404 only) > > handled? Maybe that one should be changed and/or configurable > in server.xml? > > > > As of Tomcat 4.0.1, error pages are handled in > org.apache.catalina.valves.ErrorDispatcherValve, which is attached at the > Host level. > > > Is there anything I can do for now besides duplicating filtering logic > > directly in my 404? > > > > > > > > (*) In a web-connected environment, you must ensure that your > > > configuration respects this requirement. The mod_webapp > > > connector understands it already, but mod_jk must be explicitly > > > configured to forward requests for static resources that must > > > be filtered. > > > > That's no problem since I use stand-alone mode only. > > > > > Craig > > > > Greetings, deacon Marcus > > > > > > Craig > > Greetings, deacon Marcus
