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 Tue, 28 Dec 1999 20:38:40 GMT
Craig,

I like your proposal for Tomcat.next and the layered container
architecture.

I've just implemented an interceptor that hooks Tomcat into a J2EE
back-end called Tyrex (transactions, JNDI naming context, JDBC
connection pooling) so I can give you feedback on that part.

Tyrex requires a global interceptor that was available to all servlets
running inside the container and had to be available at startup. The
interceptor had to be the same across all context, but had to be context
sensitive. For each context I would populate a different set of
environment attributes in the JNDI namespace.

To get the interceptor up and running I've added an Interceptor element
to server.xml, read it upon startup, created the interceptor and
associated it with all the context managers. I can submit the necessary
patches to have that working in 3.0.

To get context-specific information I had to keep my own mapping into
contexts. I would prefer it context could hold additional parameters in
some sort of hashtable so that interceptors can reuse them.
Alternatively, a difference interceptor instance can be created for each
context. This will work better is interceptors are specified both
globally (for all contexts) and locally (per context manager).

Specific to the Tyrex, I had to read information from the deployment
descriptor (web.xml) and populate it into the JNDI naming context. This
required me to duplicate the web.xml reading code from Tomcat and
re-read the deployment descriptor the first time a context is
encountered. Perhaps the container should expose the deployment
descriptor to the interceptor through the context interface.

As for XML configuration, I am not sure passing a DOM DocumentFragment
is the best approach. For one, I would rather recieve SAX events since
I'm using a SAX->Java binding, rather then the DOM->Java binding used in
Tomcat. In fact, I would rather recieve an InputStream, since this will
allow me to register my own entity resolvers for the DTD and external
entities, something I cannot expect Tomcat to do for me.

I did not get to play much with the interface for security providers,
but definitely what I would like to see is a chained architecture where
a series of security providers are queried and the first one to response
gets to supply an interface fulfilling getPrinicpal, isInRole and
isSecure. That would allow one layer to try authentication against a
local password file, another layer to try authenticating with the
certificate, another to use LDAP and the last one to log an
unauthenticated error.

Once again, a security provider might need access to the deployment
descriptor in order to decide which realm to use, or what properties to
apply to this realm.

Last, there should be a way for Tomcat to tell an interceptor which
logger to use by supplying a PrintWriter at this point, a logger later
on (there's a JSR for a logging facility API).

arkin



> > Dear Tomcat folks,
> >
> > As my (slightly belated) Christmas present to the community, you will
> > find my proposal for a new architecture for the core servlet processing
> > components of Tomcat at the following URL:
> >
> >     http://www2.mytownnet.com/tomcat
> >
> > (This is obviously not any sort of "official" Jakarta or Tomcat web site
> > -- it is simply a convenient place to discuss the details of a fairly
> > complex proposal without creating huge messages on the mailing list).
> >
> > Those of you who are familiar with Apache JServ will recognize that the
> > proposed architecture is very similar to the remodel that was in
> > progress there before the Jakarta project was announced.  The new
> > architecture will make possible the use of Tomcat as the core servlet
> > processing component for many varied environments, as well as supporting
> > the inclusion of site specific request processing code, through the use
> > of the Interceptor concept (similar to the Valve concept from Apache
> > JServ).
> >
> > Please consider this a proposal for a major remodel of the
> > org.apache.tomcat.core package.  Because it will require such
> > significant changes (both in the code and the configuration files), I
> > would suggest we consider this the basis for a new major version of
> > Tomcat (4.x), so that bug fixes and enhancements can be made
> > simultaneously on the 3.x tree for the current version.
> >
> > Merry Christmas (yesterday :-), and Happy Y2K Day!
> >
> > Craig McClanahan
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Mime
View raw message