tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <>
Subject Re: You have to break eggs to make an omlette [was: LONG TERM PLAN]
Date Tue, 11 Jan 2000 20:52:25 GMT
On the topic of web.xml, can Tomcat either provide the web.xml
information in the form of deployment objects or a document locator?


> will _have_ to parse the request and to read a web.xml file.
> I can say that 90% of the code is ( or should be ) outside core.
> Session and Manager show one thing - it is very easy to bridge from
> one set of interfaces to the other.
> It is easy and clear to even have the 2 models running at the same time:
> Context.setManager() and Context.setSessionManager() ( the 2 proposed
> and conflicting implementations), and tomcat will use whatever the
> user configured in.
> Yes, a session manager that implements Manager will not be as
> flexible as a SessionManager, but it will be clearer and will not have
> unused parameters in methods. Who cares ? - as long as we can
> use both, the user will benefit.
> The ideea of keeping both in the main branch is exactly that -
> will allow the user to decide what model he wants, or to
> compare the 2 and then use one.
> Craig seems prety convinced that the "hierarchy of Containers"
> is the way to go and will probably implement it shortly,
> and I'm convinced that "Interceptors processing Request"
> is better and I'm going to work on it.
> As soon as Craig gets up people will have 2
> choices - in the main branch.
> The only important thing is to agree on interfaces or provide
> bridges. It's clear that the current code base has a lot of
> usefull code, while is just a set of interfaces.
> It's the individual developer's decision to develop
> for one or the other - and as long as we have bridges we
> can share the new code.
> > My main concern, as I have said before, is that Tomcat.current's lack of
> > documentation and comments makes it very hard to grasp for people who has
> I will work on this - I just need time and maybe help.
> Or just read Apache documentation, as the model is very similar.
> ( with Java instead of C and a slightly different interface, since we
> benefit from OO ).
> > could also serve as a starting point. The main point is that I believe
> > it will be much more efficient long term and allow more people to participate
> > if we start from scratch on a new branch than to cleanup and document the
> > current implementation. If we don't do that, I'm afraid Costin and a few
> Both architectures are based on modules behind interfaces. It's the modules
> that need to be written in both cases.
> Project that are needed in both and Tomcat.current:
> -class loader
> -admin tool ( the interfaces are similar, it's just few method names that are
> different)
> -better parser
> -load balancing
> -aliases
> -documentation on how to start it up
> Use whatever architecture you want to implement a faster parser and
> mapper - I'll port it to the other architecture. Implement the
> class loader for either of them, and it will work in the other with
> small cosmetic changes.
> Costin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message