geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Virtual Hosts
Date Mon, 16 Jan 2006 22:46:18 GMT
On 1/16/06, David Jencks <> wrote:
> I'd be only very unhappy if we created a second configuration
> containing the new host gbean.  I would do my best to prevent by any
> means I can think of having building one configuration modify
> another.  That is fundamentally contrary to the architectural ideas
> geronimo is built on.

Gee, tell us how you really feel...  :)  OK, moving on then...

> I am strongly against forcing limits on one component in an attempt
> to get them to comply with restrictions of another component.  I
> think this is such an attempt.

Well, yes and no.  It would be saying something like, there must be a
GBean to represent a virtual host, and that GBean must have a set of
host names associated with it, and any application can be associated
with that "defined virtual host".  For Tomcat, this would be
effectively a HostGBean with all that entails.  For Jetty, it would be
a GBean holding a list of Strings that get applied as virtual hosts
when the app is associated with that "defined virtual host".

So it's not really limiting what you can do in Jetty per se, it's just
moving the list of host names out of the web plan and into a central
server-wide (or at least web-container-wide) configuration object.

I do think it makes a little more sense that way, as the notion of a
virtual host really is not "part of an application" but is closer to
"part of the server".  It would make our Jetty configuration slightly
less flexible in that you'd need to define the virtual host in the
server and then refer to it in the web plan, instead of just listing
arbitrary host names directly in the web plan.  But I don't think
that's really that much of a limitation, it would happen to let us
significantly streamline the process for both Jetty and Tomcat, and
finally, I do kind of like how WebLogic lets you define servers and
clusters and then say which applications should be deployed to which,
and I think it would actually be a plus to model our virtual hosts
after that.

> I have an alternate proposal that I think might work.  Let's make it
> really easy to construct host gbeans in a tomcat plan or tomcat
> config in a generic web plan.  These host gbeans will go in the app
> that defines them.  This will put the problems squarely in the users
> lap, but help them solve them easily.
> So, we could have something like a choice of host-ref that takes a
> name and looks for an existing host, and host that takes a name and
> has multiple alias subelements: this would create a new host with the
> given name and aliases.

I would say that's my second choice -- only because you can run into
problems if you put the same virtual host settings in two WARs that
should both be deployed to the virtual host.  It makes more sense to
me to configure the virtual host once in the console/web container and
then have multiple apps refer to it, if we can do that in a way that
will be the same for both Tomcat and Jetty (and I think we can make it
the same process for the user, just have it generate slightly
different GBeans under the covers).


View raw message