geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@apache.org>
Subject Re: Virtual Hosts
Date Mon, 16 Jan 2006 19:56:34 GMT


Aaron Mulder wrote:
> All right, hang on.
> 
> Let's say you have App A that wants virtual hosts 1, 2, and 3 and App
> B that wants virtual hosts 2, 3, and 4.
> 
> Tomcat can have Host123 listening on 1, 2, and 3 and Host234 listening
> on 2, 3, and 4, and App A bound to Host123 and App B bound to Host234?

No....IIU what you are trying to say...

Lets differentiate between listening on an IP and VH.  The IP address
that one listens on is controlled by the connector, not the host.

The host controls which DNS resolved name it responds to...i.e.
www.example.com, etc.  You would only use an IP address for a VH if your
user actually uses the ip address in the URL, since this ultimately is
where the decision is made.  This is rarely the case of ever.

So, using your example above, assuming 1,2,3,4 are the DNS resolved
names, the setup is invalid.  Host123 and Host234 cannot share listening
for VH 2 and 3.  You must split them up...like Host12 and Host34.  But
even in this scenario, you could not attach a context to listen to
1,2,3,and 4.  To do this, you would need a single Host1 with aliases
2,3,and 4, or Host1234.

Does this make sense?

> 
> If so, we could bind each app to an existing Host or create a new Host
> with exactly the set of virtual hosts that the application needs, and
> there would never be any conflict?

The dynamic creation of a host is no problem and I was marching down
that path, until I hit the snag that you just described.  I do not think
I can apply a context to more than one host object.  IIUC, this would be
an error condition.

> 
> Thanks,
>     Aaron
> 
> On 1/16/06, Jeff Genender <jgenender@apache.org> wrote:
>>
>> 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!
>> Well, its not that common. In EJB web services, Tomcat will only bind
>> the first one from a host perspective, and ignore the rest, where Jetty
>> will bind to all listed hosts.  The first one can be associated with
>> multiple virtual host names, as long as they are declared at the host
>> object with the alias parameter.
>>
>>> My understanding of the problem here is that Tomcat can only take a
>>> single virtual host name, while Jetty can take many.  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.  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.
>> No...this is not correct.  Two hosts *can* listen on the same IP. What I
>> believe that you cannot have is a web context attached to 2 hosts.  So
>> if I have localhost on one hosts, and www.example.com on the
>> second...you cannot have a context that has both localhost and
>> example.com, if they are different host objects.  What you can do is
>> have the virtual host aliases set at a single host and thus is works.
>>
>>> Right now, there's separate, container-specific virtual host
>>> configuration for Tomcat and Jetty -- even the elements are named
>>> differently.
>> Correct.
>>
>>> 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.
>> Again, its not that simple.
>>
>>> I propose we do this:
>>>
>>>  * Add a 0-or-1 <virtual-host> element to geronimo-web, immediately
>>> before the container-config element
>> +1
>>
>>>  * Leave the existing 0-N <virtual-host> element in geronimo-jetty-config
>> +1
>>
>>>  * 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)
>> +1
>>
>>>  * Remove the <host> element from geronimo-tomcat-config and geronimo-tomcat
>> +1
>>
>>>  * 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)
>> +1
>>
>>>  * 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.
>> This is a problem here.  What happens if I have 2 virtual host names and
>> they each refer to different Host objects?  IIUC, this is illegal since
>> I cannot have 2 hosts for a single context.
>>
>>> 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.
>>>
>>> Would that work for everyone?
>>>
>>> Thanks,
>>>     Aaron

Mime
View raw message