geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Virtual Hosts
Date Mon, 16 Jan 2006 23:22:06 GMT

On Jan 16, 2006, at 2:46 PM, Aaron Mulder wrote:

> 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.

Ok, I think you are close to convincing me.  I really don't have  
enough experience to judge whether what you propose will be easier or  
harder for our users.  I think both you and jeff are saying you think  
this will be easier for our users.

IIUC correctly, the idea is to make gbeans that have (in some way) a  
list of virtual hosts inside, and for tomcat we will check that these  
lists are all disjoint, and for jetty we won't restrict the lists.
>> 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).

I'm not completely thrilled at having the web console add gbeans to  
the base web server configuration, but this seems like the best  
proposal so far.

david jencks

> Thanks,
>    Aaron

View raw message