tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: catalina extensiblity, WAS: Re: catalina realms
Date Wed, 13 Sep 2000 20:38:19 GMT
Dave Harms wrote:

> Craig,
> > Yep :-).  That can be undone if it would be useful.
> >
> Not for me at this point - I'm looking again at intercepting all
> requests in preService and handing security from there via a central
> controlling servlet (similar to what you do in Struts, but I don't
> have the luxury of mapping everything via a special file extension).

Intercepting requests is actually how container-managed security is
implemented in both Tomcat 3.x (with a RequestInterceptor) and Tomcat 4.0
(with a Valve).

An additional option you will have under Tomcat 4.0 is to use a Filter --
a feature of the 2.3 servlet spec that acts very much like a Valve.  This
means you can write portable security interceptors and things like that.

> Any idea what the performance gain with a final JDBCRealm is, esp. as
> related to the time taken up with db access itself?

The actual differences relate to the bytecodes that get generated for
references to the public methods.  These references can be direct on a
"final" class because the compiler knows that the methods cannot be
overridden by a subclass.  For non-final classes, the compiler has to
call the (internal-to-the-JVM) code that checks for an overload, so that
it calls the method in the subclass instead.

In the big scheme of things, especially for something that's going to do
database I/O, the difference is not going to be statistically
significant.  But I trained my fingers to type "public final class"
without thinking about it years ago ...

> Dave


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

View raw message