tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anil K. Vijendran" <Anil.Vijend...@eng.sun.com>
Subject Re: Proposal: request processing cleanup
Date Thu, 06 Jan 2000 22:23:57 GMT
I think what you are asking for are notions like:

  1. server-level interceptors (global)
  2. context-level interceptors (per-context)
  3. session-level interceptors (per-session)

All requests are processed by the global interceptors.

Context-level interceptors are notified of context lifecycle events as well as
when a request is being serviced by a particular context.

Session interceptors are notified of session-life cycle events as well as when
a request is made for a particular session.

Ordering needs to be defined for all these.

I didn't see interceptors with different granularities in Costin's proposal.
But I suspect it would be possible to add these when the new cleanedup
infrastructure is in place.

Assaf Arkin wrote:

> 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?
>
> arkin
>
> > 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 ).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

--
Peace, Anil +<:-)



Mime
View raw message