tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bergsten <>
Subject Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container
Date Sun, 09 Jan 2000 21:57:13 GMT
I didn't get a chance to look at the proposal until yesterday, so sorry for
the delayed response.

I like the model and to me it seems to fulfill the stated goals, and actually
provides a lot of flexibility beyond these goals. Great!

I have some comments related to the areas that have been discussed over the
last few days, and a few questions of my own.

Should the Interceptor be part of the Servlet API?
No, I agree with what Craig said: "Interceptors should be a server extension 
mechanism, not an application layering mechanism," and this means it doesn't
belong in the Servlet API.

But the Servlet API need, IMHO, to be extended with mechanisms for response
filtering (see below) and application controlled access control.

Many web applications, e.g. "groupware" apps like OneList, need to use a
security scheme where new groups and users can be added dynamically by the
application itself. Today this can only be done using one of the models
Craig described in another mail in this thread; none of them is very attractive
to me. 

I believe this requirement can be satisfied by adding a new attribute to
the form-login-config element in web.xml, e.g.

  <!ELEMENT form-login-config (form-login-page, form-error-page, auth-class?)>

where auth-class is a class that implements an Authenticator interface, e.g.

  public interface Authenticator {
    boolean authenticate(String user, String password);
    boolean isInRole(String user, String role);

It can be implemented in Tomcat through the Interceptor mechanism, and through
other mechanisms in other servlet containers. An implementation of Authenticator
can provide other methods used by the application to manage the user and
groups known by the Authenticator. This way the application can be developed
the same way as with regular container provided authetication, while parts of
the app can still update the security database.

This is, however, a discussion that belongs in the Servlet expert group,
not here.

Should the Interceptor support response filtering?
Like others, I feel that the Interceptor should not have write access
to the response. Allowing write access to the response makes the Interceptor
part of the application, which was not the intention.

Filtering needs to be dealt with in the Servlet API though, but it can be 
done with a separate mechanism. One way may be to add methods in the ServletResponse 
to allow for ResponseBodyFilter chains. But this is also a discussion that is 
probably better to have in the Servlet API expert group than here.

Revolution vs. evolution
It seems like this discussions came to the conclusion that we should do
both; move towards when we clean up the code, and possibly
start from scratch with a "refactoring" effort in a separate CVS directory (not
a branch). I can live with this approach, especially since I see pros and
cons with both approaches and can't say which one is the "right" one ;-)

A couple of questions that I have not seen any discussion about yet are:

* Why are Request/Response representations of HttpServletRequest/Response
  instead of ServletRequest/Response?

* What's the motivation for calling Interceptor preService() in LIFO order
  and postService() in FIFO order? To me it would be natural to use LIFO
  for both, but I'm sure I'm missing something here.

So, thanks Craig for a great proposal. I hope we can get there soon.

Hans Bergsten
Gefion Software

View raw message