Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
From: costin@eng.sun.com
Sender: costin@engmail3.Eng.Sun.COM
Message-ID: <38273D59.DDC9F2A5@eng.sun.com>
Date: Mon, 08 Nov 1999 21:15:05 +0000
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: Connector -- Context Manager relation
References: <3824AA3D.B3F1C87C@interdata.com.pl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Just wanted to ask - why connector is attached to context manager, not
> to server? It is potential source of problems in case someone wants to
> make his tomcat to serve for several vhosts.

ContextManager is the main "entry point" in the servlet engine. Adapters
will construct a Request/Response and call ContextManager.service.
( for request processing ).

ContextManager should be  a "singleton".

One "Context" can have multiple "Connectors" ( i.e. you can access the
same
application via multiple protocols ).
One Connector can serve multiple Contexts.

Right now this is not implemented completely - and I don't see it as a
big
priority ( compared with other features, testing of the model, etc).


> Normally he would probably use just one address:port to attach it to
> apache. However what happens if he configure two contexts with exactly
> the same connector? Supposedly he will get unable-to-bind exception,
> right?

I don't think so - there is one ContextManager, it has several Connectors
( each
using different ports ).
You should be able to set a Context to use a certain connector ( the
current code
allows all connectors to see all Contexts ).


> IMHO, connectors should belong to <server>... The relation between the
> connector and the context manager is based on the vhost, which is
> calculated during request processing phase, so it's not wise to assume
> this relation earlier.

"server" means too many things, I prefer ContextManager ( implements
Server ) :-)

There is no relation between Connector/Adapter and vhost - ContextManager
will
extract the local address and host header and do the routing ( eventualy
using hints from
RequestAdapter if the adapter already knows the vhost or the context id )

Costin