tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@exoffice.com>
Subject Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container
Date Thu, 30 Dec 1999 20:35:49 GMT
> Right, but as you write when people see "stuff you can do with either
> one", that triggers "flexibility syndrome" where you don't know you've
> taken the wrong path until it's too late. I've always tried to provide
> one and only one path to a solution, after having understood which one
> is the best globally.

100% with you. Documentation should cleary specify that Servlets are for
applications, Interceptors are for plug-in services, never mix the two,
never have a cross dependency, and always assume a Servlet will be
deployed with any given set of Interceptors and vice versa.

And don't go building application engines using Interceptors.


> Correct. Totally. In fact, if you place XSLT transformation into an
> interceptor, that sounds like you'll be bound to Tomcat for life.

Precisely.


> > Consider a security service implemented as a response-changing
> > interceptor. Whenever a request is made the service checks whether the
> > connection is secure and the user is authenticated, and if not, displays
> > an "access denied" page.
> 
> Hmmmm, I wish it was that easy. What if you accessed your page thru a
> WAP device or a VRML client? Will your introspector be able to do this?

In case of a WAP device I will most likely need to use a different
Interceptor by running in a different context. In case of VRML, I should
simply not use this functionality of the Interceptor, or I can ask the
Interceptor to activate a different Servlet that will display the proper
code based on the user agent.

Keep in mind, I'm not talking about replacing application login with an
Interceptor. I'm talking about deciding to deny access so the Servlet
never gets a chance to execute. Maybe I have some insecure Servlets on
my machine that don't check permissions at all. Maybe I want to deny
access from a given IP. That stuff is too environment specific to be in
a Servlet. 


> True, you can picture something like this
> 
>  request  --> Interceptor --> Cocoon --> Interceptor ---> response
>                    |            |             |
>                    +--------> Engine <--------+
> 
> where both your interceptor hooks to the Cocoon engine which provides
> all the functionality, but makes Cocoon functionality depend on the
> availability of interceptors, which is wrong.

Bad bad bad.

But my Interceptor can always redirect the request to a different URI.
It doesn't know if that URI is Cocoon or not, just that it's safe to
call this Servlet if the authentication failed.


> True, but the question is: should introspectors change request/response
> payload?

Either directly or have another way of doing it.

> For error pages, redirection would be just as poweful.

Assuming you have the proper Servlet in there. What if I dump an
Interceptor into Tomcat and have no way of determining whether the error
page or error Servlet exist. My Interceptor should still be able to do
something useful. Maybe not WAP or VRML, but something.


> Also, do we really need that post-processing() stage? (that screams to
> be used for filtering all over the place)

Yep. Interceptors must be called before and after Servlet invocation.
You're thinking about Servlet processing, but there are other
circumstances where you need to clean up after the Servlet.

For example, Tyrex must be called at the end of a Servlet invocation to
rollback an open transaction and release all open connections, in the
event the Servlet did not terminate properly.


> 1) there's a clear need to intercept the input, do we need to intercept
> the output?

Maybe in such a way that only allows the output to be replaced in whole,
but not filtered. Let's say my Interceptor decides to use a Servlet on a
remote machine. It will invoke that Servlet and then send it's response
back. This Servlet is the redirection mechanism.


> 2) should the interceptor allowed to "filter" the request payload? I
> think not.

I agree with you about FS on this one.

> 3) should the interceptor be able to generate a response and skip the
> servlet? yes
> 
> Let's not blind ourselves with the search for symmetry. Let's put more
> into it that simple geometric reasons.

So far you and I are in total agreement, despite looking at the picture
from two separate perspectives.

arkin


> 
> Craig, besides servlet benchmarking (which can be hardcoded inside
> Tomcat), what did you picture post-process doing?
> 
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------
> 
> ---------------------------------------------------------------------
> 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