tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Vowles" <>
Subject Re: Multi-homing/Virtual named hosts
Date Sat, 01 Apr 2000 23:00:08 GMT
----- Original Message -----
From: Costin Manolache <>
To: <>
Sent: Sunday, April 02, 2000 4:34 AM
Subject: Re: Multi-homing/Virtual named hosts

Ok, it appears we are getting the wrong ends of sticks here, so I will try
and clarify my position and see how you can explain how I should progress. I
suspect this all stems a misunderstanding on my part from ContextManagers
and how they get passed around.

> > 2) It appears that ContextManager would need to be changed to handle
> > anything other than a simple path - was this expected?
> Context yes, I don't see the problem with ContextManager - it doesn't care
> about virtual hosts, it just deals with Request/Responses.

But this appears to be where your statement doesn't make sense - the
SimpleMapper depends _very much_ on how contexts are stored in ContextMapper
to find the context that is correct for the current request. Take the
following method (from SimpleMapper)

    Context getContextByPath(String path) {
 do {
     ctx = cm.getContext(path);
     if (ctx == null) {
         int i = path.lastIndexOf('/');
  if (i > -1 && path.length() > 1) {
      path = path.substring(0, i);
      if (path.length() == 0) {
          path = "/";
  } else {
      // path too short
      break lookup;
     } else {
 } while (ctx == null);

 // no map - root context
 if (ctx == null) {
     ctx = cm.getContext( "" );

 return ctx;

This method is called by contextMap to determine the context that is
required by the request - simply put, it cycles through the path request,
lopping bits off the end until it finds one that matches a context "path"
attribute and once found, returns it. This is my interpretation of the code.

Now, lets see what that cm.getContext(path) does:

    public Context getContext(String name) {
 return (Context)contexts.get(name);

Hmmmmmmmmmm - this means that the context is being indexed on its _path_ -
which is absolutely no use in the situation of multiple contexts with the
_same_ path (two virtual hosts each with / for example).

This has to mean one of two things, either (a) VirtualHosts have to be
defined OUTSIDE of ContextManagers, or (b) ContextManagers will need to deal
with a more complex mechanism for determining the path. As I discuss this
more and more, I am leaning towards (a) - but I have yet to figure out from
the rather voluminous source code exactly how context managers get set...
(any points in this regard would be helpful) (a) would also seem to map more
closely to your comment:

> ContextManager is the "controler" - it just maintain the collection of
> ( without knowing the semantics or relation between contexts), the
> collection of interceptors ( that will know how to manipulate Req/Resp and
> Contexts) and the adapters. It doesn't have to know about what's inside
> Context or Request.

> > 4) The Ajp12 (and others?) handler would then need to be fixed to get
> > right context, as the context is being derived solely from the path, and
> > moved later on when the server name is found.
> No problem - it's done. The virtual host is already there, and all web
> we support (Apache, IIS, NES ) can deal with virtual hosts.

Er, not quite. Again, to quote from the source code in, in the AJP12RequestAdapter, one sees the
following lines (readNextRequest):

      contextPath = ajpin.readString(null);               file://Zone
      // GS, the following commented line causes the Apache + Jserv + Tomcat
      // combination to hang with a 404!!!
      // if("ROOT".equals( contextPath ) ) contextPath="";
      if("ROOT".equalsIgnoreCase( contextPath ) ) contextPath=null;
      if( doLog ) log("AJP: CP=" + contextPath);

      if( contextPath!= null )
   context=contextM.getContext( contextPath );

It is again, just assuming a path. This is fine if there is only one
"virtual" host, but the host is yet to be determined (it occurs a few lines
further down), which, if choosing the (a) option above would determine the
contextManager to actually use in this case. My simple preference would be
to not attempt to determine the context at all in this location.

> > 3) The ServerName property can appear un fully qualified, which means
> > either (a) the server would need to fully qualify a domain name
> > (which shouldn't be too nasty as the name service mechanism on the local
> > machine should have cached it) or (b) require partial matching. Which
> > be supported? I think partial matching will slow it down.
> I don't know - we should check with existing implementations ( like

Anyone out there know? It would save me a lot of work trolling through years
of feeping creaturism.


View raw message