tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@exoffice.com>
Subject Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container
Date Wed, 29 Dec 1999 00:12:12 GMT
> By the way, if you're interested in contributing any of this stuff to Jakarta,
> I've got commit privileges.  I'm sure the code would be welcomed.

Yes I am. And at this point I'm pretty confident with the code, so I'll
send you the patches in a separate e-mail.


> As a general rule, interceptors will know the container to which they are
> attached, so they can access other resources associated with that container.  In
> the case of a Context container, you will have access to the associated
> ContextConfig object (representing the "web.xml" deployment descriptor) so you
> can get whatever you want.

Beautiful.


> My thought was that the ContextConfig class would represent the entire "web.xml"
> file (whether Tomcat actually uses it or not), which you'd then be able to
> retrieve as a property of the Context container.  That way, you wouldn't have to
> parse anything from web.xml again.  That doesn't solve reading from server.xml,
> though -- the next topic you addressed.

Ditto.


> My thinking was that, during Tomcat's initialization, someone would have parsed
> the server.xml file already.  As soon as it ran into an element like <context>,
> it would instantiate a corresponding component (an implementation of Context for
> this example), and then hand the entire <context> element to the configure()
> method.  For components that are arranged hierarchically, this is elegantly
> recursive -- as soon as the the Context component's configure() method sees a
> <realm> element (to instantiate a Realm component), it plays the same game.

That depends on how generic server.xml is. For example in Tyrex you can
specify the mapping between resources (e.g. JDBC connections) to
resource references appearing in web.xml. Right now there's a master
resources.xml file with each entry specifying what application (i.e.
Servlet or context) it maps to. It would be easier to manage if the
resource information fell underneath the context element in server.xml.
But for that it must be an any content model, since you can't tell which
DTD will be used.

Let's say the <context> has zero or more <realm> elements, each one with
the name of the interceptor it maps to. When an interceptor is attached
to the context, it gets the contents of the <realm> element with the
same name. I'm not sure the entire context should be handed to the
interceptor. The other parameters there are specific to Tomcat and
should only be exposed through the ContextConfig interface. The
interceptor has no way of reading attributes that are implied, e.g.


> Since we're all reading out of the same server.xml file, giving you an input
> stream means:
> * Figuring out where the end of this element is
> * Synthesizing an InputStream implementation that covers only
>   the appropriate byte range
> * Calling your config method
> * Advancing the file pointer
> 
> Is there any existing mechanism that can convert a DOM document fragment into a
> stream of SAX events?  That way, people could use either DOM tree-walking or SAX
> event-processing approaches to configuration, as they prefer.

You're right about streams. I was thinking of a separate configuration
file that is just named in server.xml, but if the information is
included in server.xml, a separate stream makes no sense. So it's either
DOM or SAX. SAX->DOM and DOM->SAX tree walkers are easier to write,
either there's one in the Xerces samples, or I'll writer one for you.

Mime
View raw message