request interrupt

[jason watkins <ja...@pobox.com>]

Ok, we'll try again

the goal is to interrupt the handling of each http request, in order to
manage cookies, security, and write to a log. can this be done within
tomcat?

jason

----- Original Message -----
From: "jason watkins" <ja...@pobox.com>
To: <to...@jakarta.apache.org>
Sent: Thursday, September 28, 2000 5:53 PM
Subject: Global Site logging


> I'm currently using Tomcat3.1 on IIS5, out of process with redirector.
> However, I'd like any solution to be apache compat if possible, generic
> servlet container compatible way even better.
>
> What I want to do:
> For each http request under www.domain.com/, insert the http headers into
a
> table, this later (periodically) will be loaded by my data warehouse
system,
> which will update itself as nessisary then merge the log into it's own
logs.
>
> Now, the question is, how can I go about doing this? Performance isn't a
> huge worry.. the individual users latency should be low, but the number of
> cuncurrent users should be quite low.
>
> Traditional approaches to this involve parseing the httpd log files,
however
> I want to write a unique browser_id and session_id to each client when
> applicable.
>
> I could easily do this by writing a fetch servlet, and adjusting all my
> URL's to be http://host/fetch?/services/prices.html or similar, however
I'd
> like to avoid that. I'd accomplished the same using URL rewriting on
Apache
> and PHP, and it ended up being an incredible pain, since there was little
> way to restore the proper context to the dispached url.
>
> This also implies that I either want to spawn a thread, or more likely,
> dispach and include the output into my master servlet, so that the logging
> insert work trails after client's content has been delivered.
>
> Any thoughts?
>
> jason watkins
>
>
>
>

Re: request interrupt

[Steve Weiss <sw...@aamc.org>]

jason watkins wrote:
> 
> > With the servlet 2.2 API (i.e. any Tomcat 3.x version), the only way you
> > will be
> > able to do this inside Tomcat (you might see if there is an Apache
> > module that
> > does what you want if you are running Tomcat behind Apache) is to map
> > all
> > requests for your app to a particular servlet, and then teach your
> > servlet how
> > to forward the request on to the appropriate "real" servlet or JSP page.
> > Depending on the details of how your request URIs are set up, this can
> > be pretty
> > intricate to set up.
> 
> This is what I feared, and also what I did with PHP. So, I think I'll write
> a logger servlet, and just manually call it from the end of every
> page/servlet for the meantime.
> 
> > With the servlet 2.3 API (i.e. Tomcat 4.0), you will be able to do
> > things like
> > this with the new Filter API, which lets you insert processing elements
> > into the
> > servlet container's processing stream, independent of the servlets that
> > ultimately get invoked.  In this scenario, what you want to do should be
> > pretty
> > easy.  For example, one of the example filters in Tomcat 4.0 is a
> > debugging aid
> > that just dumps out all the request headers to a log file.  All you have
> > to do
> > is configure this filter to watch the URI patterns you are interested
> > in, with
> > no changes to the rest of the webapp.
> 
> awsome, this is totally nessisary!
> 
> any ETA on when Tomcat 4.0 and the 2.3 spec are going to move to ready for
> prime-time?

I've accomplished this by a slightly different approach, which seems to
work pretty well (although it may require a little more work). I just
created my own version of HttpJspBase.java (i.e., MyAppJspBase.java),
and added debugging and authentication code (and whatever other
functionality I want available to all JSPs). Then I just have all JSPs
extend that base class and they can call whatever specific code I need
(open source is nice :).

I did the same thing for servlets- create a base class which all our
servlets extend. I think I prefer having control over this kind of stuff
in my own code, seems like it would be more portable but I'm sure
ymmv...

-Steve
-- 
Steve Weiss      Association of American Medical Colleges
(202)828-0428    mailto:sweiss@aamc.org    http://www.aamc.org

Re: request interrupt

[jason watkins <ja...@pobox.com>]

> With the servlet 2.2 API (i.e. any Tomcat 3.x version), the only way you
> will be
> able to do this inside Tomcat (you might see if there is an Apache
> module that
> does what you want if you are running Tomcat behind Apache) is to map
> all
> requests for your app to a particular servlet, and then teach your
> servlet how
> to forward the request on to the appropriate "real" servlet or JSP page.
> Depending on the details of how your request URIs are set up, this can
> be pretty
> intricate to set up.

This is what I feared, and also what I did with PHP. So, I think I'll write
a logger servlet, and just manually call it from the end of every
page/servlet for the meantime.

> With the servlet 2.3 API (i.e. Tomcat 4.0), you will be able to do
> things like
> this with the new Filter API, which lets you insert processing elements
> into the
> servlet container's processing stream, independent of the servlets that
> ultimately get invoked.  In this scenario, what you want to do should be
> pretty
> easy.  For example, one of the example filters in Tomcat 4.0 is a
> debugging aid
> that just dumps out all the request headers to a log file.  All you have
> to do
> is configure this filter to watch the URI patterns you are interested
> in, with
> no changes to the rest of the webapp.

awsome, this is totally nessisary!

any ETA on when Tomcat 4.0 and the 2.3 spec are going to move to ready for
prime-time?

Re: request interrupt

["Craig R. McClanahan" <Cr...@eng.sun.com>]

jason watkins wrote:

> Ok, we'll try again
>
> the goal is to interrupt the handling of each http request, in order to
> manage cookies, security, and write to a log. can this be done within
> tomcat?
>

With the servlet 2.2 API (i.e. any Tomcat 3.x version), the only way you
will be
able to do this inside Tomcat (you might see if there is an Apache
module that
does what you want if you are running Tomcat behind Apache) is to map
all
requests for your app to a particular servlet, and then teach your
servlet how
to forward the request on to the appropriate "real" servlet or JSP page.
Depending on the details of how your request URIs are set up, this can
be pretty
intricate to set up.

With the servlet 2.3 API (i.e. Tomcat 4.0), you will be able to do
things like
this with the new Filter API, which lets you insert processing elements
into the
servlet container's processing stream, independent of the servlets that
ultimately get invoked.  In this scenario, what you want to do should be
pretty
easy.  For example, one of the example filters in Tomcat 4.0 is a
debugging aid
that just dumps out all the request headers to a log file.  All you have
to do
is configure this filter to watch the URI patterns you are interested
in, with
no changes to the rest of the webapp.

>
> jason

Craig McClanahan

====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
                                    Applications to Tomcat