tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <>
Subject Re: Proposal: request processing cleanup
Date Thu, 06 Jan 2000 22:11:00 GMT
How can the following be achieved with the new design:

Add a global interceptor used by all contexts (e.g. a logging
interceptor, security, etc) that must be executed before some
Interceptors (and the Servlet itself) but after other interceptors ( at
least the one that determines the context)?

Be able to start/stop a specific context without affecting the other
contexts? If a context is now served by an Interceptor, could that
Interceptor expose some management functionality?

Could the SessionInterceptor be aware of a session's access boundaries
(i.e. begin/end of service request for that session) so that sessions
can be load balanced and persisted? Could (should?) the
SessionInterceptor be used to terminate a session?

Discovery of all contexts in the server so an Interceptor can be
configured externally but the configuration will correspond to contexts
set in the server?


> New model.
> This model is based on Interceptors and use the same semantics/alghoritm
> as Apache (and NSAPI, ISAPI !!) -  each request ( or sub-request) will
> follow the same path,  with several types of Interceptors processing the
> request in a specific way.
> In addition to the Lifecycle and Service Interceptors ( and the
> SecurityInterceptors as defined by J2EE or Craig's security package), we
> will have interceptors that will  parse the URI and set the Context,
> ServletWrapper and all other informations required by the spec.
>    * Request - same role ( changes: move LookupResult functionality
>      inside Request, RequestDispatcher will create a subrequest instead
>      of using LookupResult )
>    * ContextManager - same role, but instead of hardcoded parsing of the
>      request to find a Context it will call a a set of translation
>      Interceptors == RequestHandlers ( configurable - the current code
>      will be the default !).
>    * Interceptor ( or RequestHandler ??  ) - will process the request.
>      The current parsing code from RequestMapper, ContextManager,
>      InvokerServlet, Container, etc will be moved in one or many
>      handlers.
> The initial implementation will use the existing code to parse the URI
> and
> find the Context, ServletWrapper, pathInfo, servletPath, etc and set
> them
> in the Request object.
> ( please also read the Apache docs&code, with Request==request_struct,
> ServletWrapper==handler, Context==per_dir_config,  Interceptor=handler
> method in a module, etc. )
> Notes
>    * it cleans up existing code. The current code is the result of a
>      long evolution ( including the introduction of RequestDispatcher
>      and the current semantics of Context), we need something simpler
>      and easier to follow.
>    * allow better integration with web servers.  This model is similar (
>      or identical?) with Apache request processing and few other
>      servers.
>    * Will help improve the standalone server - it can use a different
>      set of Interceptors, and it is easier to experiment with faster
>      parsers
>    * You can customize tomcat for specific tasks. For example, if a
>      server has only one context and no virtual hosts it can use a
>      simple interceptor and cut 1/2 of the size ( embeded? ). This will
>      also fix several virtual-host problems in the existing code.
>    * it will keep the critical path in one place, and IMHO it will be
>      easier to read and understand.
>    * Craig: It is a specific way to process the request - with 2
>      Container layers: ContextManager and ServletWrapper. It is a
>      particular implementation of Container - it doesn't prevent the
>      hierarchy of containers as in your proposal (2.2.1).
> Implementation
> I made few experiments and the changes doesn't affect too much outside
> core.
> Most of the code is written, and assuming no absolute -1 is raised most
> of
> code can be reorganized in 1-2 weeks.
> The first step is to merge LookupResult and Request, and change
> RequestDispatcherImpl and the other classes acordingly. Second,
> RequestMapper must be transformed into an Interceptor ( i.e. made
> stateless ).
> The code from ContextManager can be moved in a Interceptor ( that will
> parse the URI and set the Context - if none is already there !).
> Some code from Context will go into SessionInterceptor - that will
> further decouple the session-related code.
> Container.lookupServlet will be part another interceptor ( or merged
> with ContextInterceptor, and use same parsing code ).

View raw message