You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Deacon Marcus <de...@wwtech.pl> on 2001/10/24 16:20:11 UTC
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
RE: Filters on error/index pages
Posted by Deacon Marcus <de...@wwtech.pl>.
Thanks,
> -----Original Message-----
> From: craigmcc@localhost.iq.pl [mailto:craigmcc@localhost.iq.pl]On
> Behalf Of Craig R. McClanahan
> Sent: Friday, October 26, 2001 1:58 AM
> To: tomcat-dev@jakarta.apache.org
> 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 <de...@wwtech.pl>
> > Reply-To: tomcat-dev@jakarta.apache.org
> > To: tomcat-dev@jakarta.apache.org
> > Subject: RE: Filters on error/index pages
> >
> > Hi,
> >
> > > -----Original Message-----
> > > From: craigmcc@localhost.iq.pl [mailto:craigmcc@localhost.iq.pl]On
> > > Behalf Of Craig R. McClanahan
> > > Sent: Thursday, October 25, 2001 12:26 AM
> > > To: tomcat-dev@jakarta.apache.org
> > > 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 <de...@wwtech.pl>
> > > > Reply-To: tomcat-dev@jakarta.apache.org
> > > > To: tomcat-dev@jakarta.apache.org
> > > > 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
RE: Filters on error/index pages
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 25 Oct 2001, Deacon Marcus wrote:
> Date: Thu, 25 Oct 2001 14:08:36 +0200
> From: Deacon Marcus <de...@wwtech.pl>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: RE: Filters on error/index pages
>
> Hi,
>
> > -----Original Message-----
> > From: craigmcc@localhost.iq.pl [mailto:craigmcc@localhost.iq.pl]On
> > Behalf Of Craig R. McClanahan
> > Sent: Thursday, October 25, 2001 12:26 AM
> > To: tomcat-dev@jakarta.apache.org
> > 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 <de...@wwtech.pl>
> > > Reply-To: tomcat-dev@jakarta.apache.org
> > > To: tomcat-dev@jakarta.apache.org
> > > 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.
> 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.
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
RE: Filters on error/index pages
Posted by Deacon Marcus <de...@wwtech.pl>.
Hi,
> -----Original Message-----
> From: craigmcc@localhost.iq.pl [mailto:craigmcc@localhost.iq.pl]On
> Behalf Of Craig R. McClanahan
> Sent: Thursday, October 25, 2001 12:26 AM
> To: tomcat-dev@jakarta.apache.org
> 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 <de...@wwtech.pl>
> > Reply-To: tomcat-dev@jakarta.apache.org
> > To: tomcat-dev@jakarta.apache.org
> > 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?
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?
> - 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?
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
Re: Filters on error/index pages
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 24 Oct 2001, Deacon Marcus wrote:
> Date: Wed, 24 Oct 2001 16:20:11 +0200
> From: Deacon Marcus <de...@wwtech.pl>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> 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
- Error page - no
(*) 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.
Craig