From Sun Jan 9 21:54:16 2000 Return-Path: Mailing-List: contact; run by ezmlm Delivered-To: mailing list Received: (qmail 79444 invoked from network); 9 Jan 2000 21:54:16 -0000 Received: from ( by with SMTP; 9 Jan 2000 21:54:16 -0000 Received: from ( []) by (8.9.3/8.9.3) with ESMTP id NAA15619 for ; Sun, 9 Jan 2000 13:53:00 -0800 (PST) Message-ID: <> Date: Sun, 09 Jan 2000 13:57:13 -0800 From: Hans Bergsten Organization: Gefion software X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Subject: Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container References: <> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. 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 ;-) Questions --------- 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 -- Hans Bergsten Gefion Software