tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Serle Shuman" <>
Subject Re: Multi-homing/Virtual named hosts
Date Mon, 03 Apr 2000 11:53:26 GMT
When considering virtual host functionality could you also address setting
of SSL certificates per virtual host. This was a big weakness in JWS2.0

----- Original Message -----
From: Costin Manolache <>
To: <>
Sent: Sunday, April 02, 2000 6:16 AM
Subject: Re: Multi-homing/Virtual named hosts

> 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
> > 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
> > when I followed the code (addContext()), it does absolutely nothing,
> > 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,
> 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
> 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
> the code is mature enough we can change the default-  and if something is
> we can go back to the (slow, ugly, old) code.
> In this particular case - yes, we need to implement addContext(), but
> 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
> > other classes (Container & ContextGroup) to see what you are talking
> Container is just a start - it represents the properties for a group of
> 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
> 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
> > file when implementing VirtualHosts - I believe that to decide on a
> > 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
> specify interceptors at Container level ( not implemented yet, of course),
> 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
> make
> the connector a property of the vhost ). I think most browsers supports
> that.
> >      <VirtualHost name="" ip="a.b.c.d">
> >         <Connector
> >             <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
> > 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
> If we can specift the facilities as context properties and keep CM as
> I think it'll be much easier. Or at least it's a good start, if we find a
> 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
> > concensus so that any code I write can be made available to others, as
> > 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
> Costin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message