On Jan 16, 2006, at 2:46 PM, Aaron Mulder wrote:
On 1/16/06, David Jencks <[EMAIL PROTECTED]> 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.
thanks
david jencks
Thanks,
Aaron
