Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <38E6C9A0.5A9D54F9@eng.sun.com>
Date: Sat, 01 Apr 2000 20:16:32 -0800
From: Costin Manolache <costin@eng.sun.com>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: Multi-homing/Virtual named hosts
References: <006401bf9b9d$5159e5c0$4bd90eca@sew.co.nz>
 <38E5950D.6F59B365@eng.sun.com> <00ad01bf9bd2$ce47e980$4bd90eca@sew.co.nz>
 <00dd01bf9bdf$102c6360$4bd90eca@sew.co.nz> <38E6251F.82D166A3@eng.sun.com>
 <001601bf9c2e$0877f090$4bd90eca@sew.co.nz> <38E68E38.46341614@eng.sun.com>
 <002801bf9c43$f48b1240$4bd90eca@sew.co.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Richard Vowles wrote:

> Ok, makes sense now!

Then you're the right person to explain that from now on, it
seems I'm very bad at that :-)

> With that message you drew two threads together of things that I didn't
> understand:
>
> (a) The fact that when setContextManager is called on SimpleMapper, it does
> this:
> - which in the ideal case would mean that it is subsuming all of the
> contexts so that it can implement its own mapping. The only problem was that
> when I followed the code (addContext()), it does absolutely nothing, which
> meant that it was confusing to me. Now it makes sense, but it needs an
> implementation.

We tried to focus on moving the dubious code outside tomcat.core and clean
up the architecture. Tocmat had a great architecture from the beginning, but
in time and with many "features" added the implementation was not so good.

SimpleMapper is based on the old code, and we tried to keep everything working.
We did many changes to support apache, and it's not a good ideea to change
everything at once. The code used to be very stable ( and I hope it still is ) -

after many rounds of testing and in previous incarnations as JWSDKs. It is
not an efficient alghoritm ( or no mapping alghoritm at all ), but it tries to
be correct - and that's very important.

In tomcat 3.2 we can focus on performance ( i.e. using efficient alghoritms and
data structures - a tree will probably do miracles), and that can be done
without
affecting the stability - you can create new modules, play with them, and when
the code is mature enough we can change the default-  and if something is wrong
we can go back to the (slow, ugly, old) code.

In this particular case - yes, we need to implement addContext(), but again,
I would do it in a new module, with a clear code.


> As for the rest of your message, I'm going to have to go and look for those
> other classes (Container & ContextGroup) to see what you are talking about.

Container is just a start - it represents the properties for a group of URLs
or locations. Right now there are 2 properties you can set - the security
constraints and the servlet.

A Container is what Apache ( and other servers ) mean by "Location"
or "Directory" ( or Object for NES). A Context is a particular case
of container - the servlet API makes it very special and allows a lot
of properties to be defined only at context level, but for most web
servers it is just one particular prefix-mapped "Location".
( it doesn't mean it's bad that servlet API is not as rich as the
native api in all big web servers - simpler is better most of the time )

ContextGroup doesn't exist yet - and I don't think we need it. It will be
just a special instance of Container, and I see no reason to complicate
the model ( I would even remove Context and have it just a special
Container, but it's too late for that - maybe in a small revolution). But if
people really want to represent a virtual host as a separate interface,
at least ( please ) use ContextGroup.

If you are familiar with apache, there are only 2 objects that matter -
directory ( == Container, with Context as the only Container where
you can set properties in servlet model ) and request ( well, you
also have connection, and it's bad we don't have such an object)

> My only remaining concern at this time is the changed structure of the XML
> file when implementing VirtualHosts - I believe that to decide on a mapping
> is a worthwhile thing so that I can progress. I'm not sure that putting
> Context's under ContextManager's make sense any longer. Here's why:
>
>     <ContextManager debug="0" home="." workDir="work" NAME="CTMGR1">

I'm not sure we need to go as far as having multiple ContextManagers. You can
specify interceptors at Container level ( not implemented yet, of course), and
that
will solve most of the problems.

I think it's better to add too many features at once - adding virtual hosts will
be a big
thing anyway, let's leave multiple CM for later ( at least I want to think a bit
more
about what interactions we'll have in this case - it's a bit too complex for me
)

About the syntax for virtual hosts - my only concern is to use a syntax
that is similar with Apache's.

Keep in mind that you can have multiple virtual hosts with the same address and
the
same port !!!! In your example it's more difficult to express that ( since you
make
the connector a property of the vhost ). I think most browsers supports now
that.


>      <VirtualHost name="my.server.name.1" ip="a.b.c.d">
>         <Connector className="org.apache.tomcat.service.SimpleTcpConnector">
>             <Parameter name="handler"
> value="org.apache.tomcat.service.http.HttpConnectionHandler"/>
>             <Parameter name="port" value="8080"/>
>         </Connector>

> I suppose the point I am trying to illustrate is one that you just made
> yourself - a ContextManager is responsible only for knowing about all the
> contexts that require certain handling (context interception and request
> interception) and to allow the "stop" implementation. I don't see why a
> VirtualHost can't use multiple contexts each of which may need different
> facilities from different context managers. Or am I way off the rails here?

If we can specift the facilities as context properties and keep CM as singleton
I think it'll be much easier. Or at least it's a good start, if we find a need
to have
multiple ContextManagers we can add them.

The model with Containers having their own interceptors gives you almost
the same thing and probably more flexibility.

ContextManager is the entry point for adapters, and we want to be able to
do some tricks inside - and it's much easier with only one CM.


> As for forcing me to accept one opinion over another, I'd rather come to a
> concensus so that any code I write can be made available to others, as is
> the general idea with this sort of thing...

I just wanted to say that my opinion is not better than yours. We need to
reach a concensus, but after discussing and finding what's best for tomcat.

Costin