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
