Costin / 3.x advocates,
I've read the catalina overview by Craig, and the link that Costin
provided. Appologies if I haven't grasped enough of the designs as yet,
still need to spend more time reading the source code. I'm just wondering
about the benefits of the designs.
As far as I can see, 3.x is pretty much a dedicated (in design terms) web
server / servlet container, and the Interceptor approach, supports this by
giving access points to the processing chain. Catalina on the other hand is
designed as a more general request processing container, the valves not
being specifc (in terms of interface/method names) to any particular phase
/ aspect of "dealing" with requests.
I'd say from first thoughts, and certainly partly due to the fact that
Craig's article argues specifically for valves and against interceptors,
I'd agree that valves appear more appealing, as far as augmenting the
processing chain.
Looking at the latest 3.x src drops, there are say ~30 methods in
BaseInterceptor, that is access points, into the request chain / context
mapping / session handling etc. This obviously gives a degree of
control/access to the internals, though does raise the question, how many
are enough? Are those enough because they now cover all the functionality a
server does? Or will a few extra be needed as time goes on? This seems a
bit brittle to me. If an extra method is added, presumably that means a new
hook into an internal api, and the code to support it. Does this mean
multiple interfaces / base classes are required? All pluggable? What about
the existing interceptors people have written? It would be really good to
hear an argument for this design? What are the benefits of it? Does it
gives the server internals better control / optimisation opportunities?
Costin's arcticle mentioned that the Handler/Wrapper classes actually allow
3.x to use valves -- is this a clean interface (I confess to not having got
that far yet) ? As simple as 4.0? It also states that some of the current
Interceptors were / could have been Valves, but but were chosen not to be,
but does really explain why.
Having said all that, will a completely generic nested container model (4.0
obviously) lend itself to streamlining, internal shortcuts and
optimisations in the same way as a dedicated web server architecture?
That's my opening set of questions, anybody?
Ken.
This e-mail message is CONFIDENTIAL and may contain legally privileged
information. If you are not the intended recipient you should not read,
copy, distribute, disclose or otherwise use the information in this e-mail.
Please also telephone or fax us immediately and delete the message from
your system. E-mail may be susceptible to data corruption, interception
and unauthorised amendment, and we do not accept liability for any such
corruption, interception or amendment or the consequences thereof.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
