geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Virtual Hosts
Date Mon, 16 Jan 2006 17:52:42 GMT
If this doesn't work for you (and it sounds like it doesn't), please
make a counter-proposal.  Certain other app servers have provided a
common virtual host element while supporting both Jetty and Tomcat, so
I know it can be done.  And if Web Services are indeed broken on
Tomcat, that only adds more urgency to solve this.

Thanks,
    Aaron

On 1/16/06, David Jencks <david_jencks@yahoo.com> wrote:
>
> 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
>
>

Mime
View raw message