> > Jon Stevens wrote:
> >> 
> >> Why does this scare me into thinking that if people
> >> start to base their code on top of this that they
> >> will be tying themselves to a single servlet engine?
> >> Isn't that something that we were trying to avoid?
> >> 
> >> Correct me if I'm wrong.
> > 
> > I see it as a good guideline, but not an iron clad rule.
> > 
> > There is precidence for it.  Take a peek at the catalina-wrapper target of
> > the jakarta-slide project, for example.
> > 
> > - Sam Ruby
> 
> I'm still confused. Back in JServ days, we were very resistant to adding
> things to the container that were outside of the scope of the Servlet
> Spec...for example, support for servlet chaining because we wanted to
> maintain our stance as a supporter of the servlet spec. I guess that this
> has changed now. Oh well.

Jon, 

Hooks are the basic design pattern used in tomcat3.x.
Same pattern is used in apache, NES, IIS ( apache2.0 has the most
flexible implementation ). 

The hooks are used to allow modules to control the server execution - it
has nothing to do with the servlet spec ( the same way "valves" are used
in 4.0 implementation ). 

It is not a new "feature" - I moved it to a separate class ( it used to be
part of ContextManger, then Container ) in order to better expose it,
since it is after all the "core" of tomcat3.x modularity. 

Like in Apache ( and most web servers I know ), tomcat3.x functionality is
implemented in a modular way, to avoid "featurism" and keep things
maintainable  ( elegant, robust, etc ). Of course, someone who is
implementing tomcat3 ( and tomcat3 features ) would have to use the tomcat
architecture ( i.e. the 8 core objects + the hook pattern + the facade
pattern ). 


Costin

Reply via email to