tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: a few comments
Date Tue, 19 Oct 1999 15:26:48 GMT
[Moving this discussion to TOMCAT-DEV where it really belongs]

James Davidson wrote:

> > 1) We need a real Logger for servlets and the engine. Is this going to
> > be moved from JSERV1_1DEV to Tomcat?
> I'd be happy to see this done. We just need to make sure that whatever we do
> is pluggable so that other folks can plug in their own logger if they embed
> the server into their application (like the J2EE RI does).

There are actually a couple different types of loggers that might be
appropriate.  Here's a suggestion on how to deal with each of them:

* The output from ServletContext.log() and friends:

    Consistent with the new packaging structure I'm working on for
    security realms, it seems reasonable to define a new package:


    with a Logger interface that matches the various log()
    signatures in ServletContext.  Context would simply
    delegate its log calls to a Logger instance whose real
    class is selected at configure time.  The default class
    would just write to System.out or whatever it does now.

    We need a consistent way to configure the class names
    of all these components.  Originally I was thinking to
    add attributes to the server.dtd, but context initialization
    parameters can deal with most of this, using mechanisms
    that already exist.

* Web server type access log:

    In JSERV1_1DEV this was done with a "Valve", which
    is somewhat similar to an Interceptor in the Tomcat
    architecture.  I haven't looked in detail, but I think you
    could do this kind of logging in a postInvoke() method.

    I want to look at the Interceptor approach in more
    depth before suggesting any changes -- but it seems
    reasonable to think that most things Valves can do
    will be possible with Interceptors as well.

* Debugging logs:

    Personally, I've felt the Apache JServ 1.0 mechanisms
    of filtering messages based on "channels" was overkill
    for a servlet container, and pretty application specific
    to boot.  For my own apps, I use ServletContext.log()
    with keywords in the message string that I can "grep"
    for to find information from a particular source, or
    related to a particular error.

> > 2) It would have been great if we could design the Servlet class
> > loader like we have in JSERV1_1DEV so that we can have pluggable
> > ClassLoaders. That way we can (e.g.) have a Java2 classloader that can
> > give servlets loaded a code source, so it's possible to control
> > security permissions for servlets loaded via a Policy file. This is
> > important in a multi hosting servlet environment, for example for ISPs
> > that are hosting servlets.
> Yep. Once again, this would be great to see.

Haven't thought about this one at all yet, but agree that it would be great.

> > 3) I hope that the Valve concept from JSERV1_1DEV will not be lost and
> > moved to Tomcat, so it's possible to pre/post process a request/respons.
> > Are there any plans for doing this?
> I don't know of any yet. Feel free. :)

As above, I think Interceptors will play this role, perhaps after being
generalized a little.  One thing we need to be able to do is intercept service
requests to the whole container, and to the ContextManager, so that an
administrator can configure things globally.  One of the needs for this
(authentication and access control) are being dealt with separately because of
the 2.2 spec requirements, but there are other reasons to want global

> > 4) What does this warning in some of the class files means:
> > // WARNING: Some of the APIs in this class are used by J2EE.
> > // Please talk to before making any changes.
> >
> >    Does this mean that development of the J2EE component collection is
> >    dependent of Tomcat? I know that Servlets/JSP are supposed to be a
> >    part of J2EE, but is this coupling so close to create limitations
> >    on class and method names/signatures?
> The J2EE Reference Implementation uses Tomcat at it's servlet / jsp
> container. This warning means that the RI team relies upon that interface.
> It's a little bit confusing as it *doesn't* mean that J2EE itself relies up
> on it. Just the RI.
> > 5) Is the Tomact package design frozen or is it possible to break it
> > up into a more general, pluggable and flexible structure like what we
> > have in JSERV1_1DEV?
> It's open source. It's never frozen. :) However, it has to be able to
> satisfy the following:
>     1) Standalone operation
>     2) Connected operation with Apache via a variety of mechanisms
>     3) Connected operation with other web servers
>     4) Embedded operation (like in the J2EE RI)
> Craig is busy in the source, so I'd bet that he's already got a plan for
> moving stuff into place. :)

I wouldn't call it a plan yet, but certainly a lot of ideas ;-).  With
JSERV1_1DEV we had the luxury of building an architecture from the ground up --
here, the pragmatic course would be to evolve Tomcat into a more
component-based architecture that makes it easier to plug in to other server
environments, easier to add connectors to, and still powerful enough to run
stand alone.  There is *lots* of fun to be had.

> .duncan


View raw message