tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@exoffice.com>
Subject Re: Proposal: request processing cleanup
Date Thu, 06 Jan 2000 22:51:57 GMT
"Anil K. Vijendran" wrote:
> 
> 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.

+1 Ordering is very important


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

+1 Ordering might be less important

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

The interceptor will be called per session, but the interceptor can only
be configured per context.

arkin

> 
> 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 +<:-)
> 
> ---------------------------------------------------------------------
> 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