Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=Vebg9mPR80SzBw7Lft7lTrP++q0YOEMol978KdIbp4rlAuadSmDMuPJt+iGUOnb9Om/ArXN7tA6sl1eBHIGp3XuVjlgEK0rexmUjrF/cTiOSlzgSUGCKRugH4Oir8e20tA1//e7NrI8Z4TyvdWQmX9Qu5bX3vUYHsTnSljPcqGg=
  ;
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <74e15baa0601160906y179176eahcd317e759403e819@mail.gmail.com>
References: <74e15baa0601160906y179176eahcd317e759403e819@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <AA72A995-490B-4509-9E77-BA0FBF9D76B3@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: Virtual Hosts
Date: Mon, 16 Jan 2006 09:46:46 -0800
To: dev@geronimo.apache.org


On Jan 16, 2006, at 9:06 AM, Aaron Mulder wrote:

> OK, it strikes me as pretty silly that you can't configure virtual
> hosts in a common way for web applications, but you can for EJBs
> exposed as web services!

I suspect the implementation for ejb web services re tomcat is wrong.
>
> My understanding of the problem here is that Tomcat can only take a
> single virtual host name, while Jetty can take many.

No, that is decidedly not the issue.  The issue is that tomcat has  
objects called "hosts" that include lists of what we are calling  
virtual host names, but have complicated restrictions on use.  Jetty  
doesn't tie anything to the (list of) virtual host names.  At the  
moment there is no way to directly specify a virtual host name in  
tomcat, that is a feature of tomcat, and I don't see why we should  
try to redesign tomcat to make it conform to jetty's way of doing  
things.

>   That name for
> Tomcat corresponds to a HostGBean which may be listening on any number
> of IPs, but no two hosts can listen on the same IP.

I thought IP was a a.b.c.d set of 4 bytes whereas a virtual host name  
was a string that could be resolved using DNS to some IP.  The IP(s)  
that may be in use are set completely independently using connectors.

> Jetty does not
> use that same Host concept -- instead you can list any number of
> virtual hosts and the web app will be bound to each of those with no
> intermediary.
>
> Right now, there's separate, container-specific virtual host
> configuration for Tomcat and Jetty -- even the elements are named
> differently.

mostly because you can't set the virtual hosts in tomcat without  
creating a host gbean, which requires careful thought about how to  
follow the tomcat rules.
>
> My problem is that we're taking this fairly common functionality, and
> making it hard to use the simple case (1 virtual host name) because we
> can't adequately model the difficult case (where you want to bind an
> app to multiple virtual hosts and Tomcat has restrictions that Jetty
> doesn't).  But again, we managed to make the simple case simple for
> EJBs exposed via the web container, so I'm sure we can do it for web
> apps.

Are you sure it works for tomcat ejbws?
>
> I propose we do this:
>
>  * Add a 0-or-1 <virtual-host> element to geronimo-web, immediately
> before the container-config element
>  * Leave the existing 0-N <virtual-host> element in geronimo-jetty- 
> config
>  * Leave the existing 0-N <virtual-host> element in geronimo-jetty,
> ensuring it's the first "container-specific" element in that file (so
> it essentially overrides the 0-or-1 element in the generic plan with a
> 0-N element)
>  * Remove the <host> element from geronimo-tomcat-config and  
> geronimo-tomcat
>  * In Jetty, we'll use all the virtual-host elements you provide (up
> to 1 in the generic plan and up to N in the container-config or
> Jetty-specific plan)
>  * In Tomcat, if any Host GBean has the same name (as in name="foo" in
> the ObjectName) as the virtual-host name, then we'll bind the web app
> to that.  Otherwise, if any Host GBean is bound to the host name/IP
> specified as the virtual-host name, then we'll bind the web app to
> that (or throw an error).  Otherwise, we'll automatically create and
> deploy a new Host GBean using the name of and binding to whatever you
> specified in the virtual-host element.

AFAIK there is no reason to think that a tomcat host name is related  
to any aliases it may contain.
This will result in truly bizarre and unintelligable deployment order  
effects.  Lets say you have 2 web apps that you want to use with the  
same virtual host, and assume each host we create has one alias named  
the same as the host (which is what I think you are assuming above).

So, we gleefully proceed to construct configs for each of these,  
since they are in separate projects we run the packaging plugin  
separately, and each one finds no host gbean with the name it wants,  
so  creates one for itself.  Now, when you try to run both in the  
same app server, you can't, because you are trying to start two host  
gbeans with the same virtual host.  If you deploy them in the same  
run of the packaging plugin, the first app to be processed will get  
the host gbean and the second one wont.  This introduces a hidden  
dependency between the two apps that is not specified in the  
deployment plans.  The same thing would happen if you deployed them  
online.
>
> That should mean we have a common configuration scheme if you want to
> bind a web app to a single virtual host.  If you want to bind to
> multiple virtual hosts, you must either use the extended
> Jetty-specific syntax, or manually configure a Host GBean for Tomcat
> that binds to those IPs and then put the name of that GBean in the
> virtual-host element.
>
> Most importantly, if you do no extra configuration but put
> "<virtual-host>virtual.host.com</virtual-host>" in the geronimo-web
> plan then it will do what you expect, regardless of the web container
> in question.

I think it will only simplify matters when each web app uses a single  
virtual host that no other web app uses.  As soon as there is any  
overlap it produces unstartable apps and unpredictable behavior.
>
> Would that work for everyone?

Definitely not, sorry

david jencks

>
> Thanks,
>     Aaron