catalina extensiblity, WAS: Re: catalina realms

[Bernd Eilers <be...@stardivision.de>]

Hi there !

> That is correct.  The "class path" for Catalina's own components 
(including
> any Valves, Realms, and so on that you write) is the JAR files found in 
the
> "server" directory.

> The "lib" directory is the set of libraries that are exposed to web
> applications as shared components.

Well why we are just at the topic of what is 'exposed' as shared 
components and what is not.

I've always wondered why there are so many final and or private classes 
and methods in catalina in contrary to that catalina started with a 
mission description of being more extensible better embeddable core 
architecture.

Why for example is it not allowed to derive from classes in the 
org.apache.tomcat.startup.* package to do some customized stuff eg. 
override start in a class derived from Catalina.java

It's an open source project there shouldn't be so much private methods 
;-)

> >
> > Paul Lamb
> >

> Craig McClanahan

Bernd Eilers

Re: catalina extensiblity, WAS: Re: catalina realms

[Dave Harms <jd...@clarionmag.com>]

Craig,

> 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.

Looking forward to it. 

Dave

Dave Harms
jdev@clarionmag.com

Re: catalina extensiblity, WAS: Re: catalina realms

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

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
>

Craig

====================
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

Re: catalina extensiblity, WAS: Re: catalina realms

[Dave Harms <jd...@clarionmag.com>]

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). 

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

Dave

Dave Harms
jdev@clarionmag.com

Re: catalina extensiblity, WAS: Re: catalina realms

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

Dave Harms wrote:

> Craig,
>
> > I always start by writing classes as "final" (to let the compiler optimize
> > things a little better), with private instance variables, unless I know ahead
> > of time that I'm going to subclass.  If later development indicates that it
> > is better to allow subclassing, I have no problems at all going back and
> > making that possible.
> >
> Ah, so that's why JDBCRealm is final<g>.
>

Yep :-).  That can be undone if it would be useful.

>
> Dave
>
> Dave Harms
> jdev@clarionmag.com
>

Craig

====================
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

Re: catalina extensiblity, WAS: Re: catalina realms

[Dave Harms <jd...@clarionmag.com>]

Craig,

> I always start by writing classes as "final" (to let the compiler optimize
> things a little better), with private instance variables, unless I know ahead
> of time that I'm going to subclass.  If later development indicates that it
> is better to allow subclassing, I have no problems at all going back and
> making that possible.
>
Ah, so that's why JDBCRealm is final<g>.

Dave

Dave Harms
jdev@clarionmag.com

Re: catalina extensiblity, WAS: Re: catalina realms

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

Bernd Eilers wrote:

> Hi there !
>
> > That is correct.  The "class path" for Catalina's own components
> (including
> > any Valves, Realms, and so on that you write) is the JAR files found in
> the
> > "server" directory.
>
> > The "lib" directory is the set of libraries that are exposed to web
> > applications as shared components.
>
> Well why we are just at the topic of what is 'exposed' as shared
> components and what is not.
>
> I've always wondered why there are so many final and or private classes
> and methods in catalina in contrary to that catalina started with a
> mission description of being more extensible better embeddable core
> architecture.
>

The basic mission is to allow you to replace components of Catalina with
classes that implement the appropriate interfaces.  The question you are
asking seems like it is really "why don't you make it easier to extend
Catalina by promoting the subclassing of existing classes rather than having
to rewrite them from scratch?"

>
> Why for example is it not allowed to derive from classes in the
> org.apache.tomcat.startup.* package to do some customized stuff eg.
> override start in a class derived from Catalina.java
>
> It's an open source project there shouldn't be so much private methods
> ;-)
>

That's mostly a result of my personal programming habits :-)

I always start by writing classes as "final" (to let the compiler optimize
things a little better), with private instance variables, unless I know ahead
of time that I'm going to subclass.  If later development indicates that it
is better to allow subclassing, I have no problems at all going back and
making that possible.

The startup classes are a good candidate for doing this -- look for some
changes to be be posted in the next couple of days.  Are there any other
classes in particular that you'd like to subclass but cannot currently?

>
> > >
> > > Paul Lamb
> > >
>
> > Craig McClanahan
>
> Bernd Eilers
>

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