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 23:02:07 GMT
> The order of the interceptors and what interceptors are called is
> configurable.

Great.


> Management is not the job of interceptors either - use the existing APIs
> or add new APIs.

I guess I'll have to rephrase my question. Given that some Interceptors
can affect the behavior of the server, should management be performed in
the server or should it be delegated into the Interceptor.

If an Interceptor is now responsible to handle processing for a context,
what would be the proper way to control that context: should I use that
particular Interceptor (e.g. ContextInterceptor) as my admin API, or
should I use ContextConfig (or anything else) as my admin API?

The second case works today, but the second case has a limitation. If I
change ContextInterceptor to MyOwnContextInterceptor, I might not be
able to use ContextConfig to control that context any more.


> > 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?
> 
> It's up to the SessionInterceptor, the model doesn't prevent this.

Question is: is SessionInterceptor called immediately prior-to/after
using a session and can the SessionInterceptor be called upon to provide
the session (e.g. automatically retrieving it from persistent storage if
none existed before)?


> The SessionInterceptor may terminate sessions - but it's up to the
> implementation of the interceptor, not in core.

OK.


> > 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?
> 
> It's a different story - server management should be independent of the
> request processing model.

Yes. But the request processing model is affected by configuration, and
there must be some way to configure the stuff.

All the Tomcat internal interceptors will use Tomcat configuration, but
an external interceptor might want to use an external configuration and
have it synchronized.

For example, in Tyrex I could define different transaction/JDBC models
that map to different contexts in Tomcat. Precisely how I implement the
mapping and what Tomcat does internally (the request processing model)
is irrelevant, I just need a *consistent and well defined* way to
associate a Tomcat context with a Tyrex context.

It will most probably not affect your design choices (which, BTW I like
very much!), only require a more explicit definition.

arkin

> 
> Costin
> 
> ---------------------------------------------------------------------
> 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