On Jan 16, 2006, at 1:07 PM, Aaron Mulder wrote:
On 1/16/06, David Jencks <[EMAIL PROTECTED]> wrote:
I'm still really nervous about trying to automatically create a host
gbean since it appears to be really a global shared object in tomcat
and creating one could cause so many difficult to understand problems
for users.
It sounded like you had a problem with creating a GBean to run as part
of an application, because then two applications could have
conflicting host GBeans. I can't argue with that. However, I had
really been thinking that if our Tomcat deployer notices that an app
refers to a virtual host that there's no existing HostGBean for, it
would deploy a new HostGBean in the server (not as part of the
application), so the first time you deploy an app with a missing host
GBean, that host GBean would be created and available to be shared by
all applications.
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.
I understand that creating things like that under the covers is not
necessarily optimal, but I'd like to avoid an end user ever needing to
deploy GBeans in order to basic server functionality to work, and I
consider virtual hosts to be pretty basic for a web app.
Another possibility is to make it easy to create "virtual host GBeans"
in the console, and then associate applications with those. We could
try to limit Jetty to behave more like Tomcat, and create "Host
GBeans" for both containers (even if it's kind of artificial for
Jetty), and have our virtual host deployment element point to those.
If they were easy enough to configure in the console (and the settings
if not the actual GBeans were portable across web containers) then I
wouldn't care that a user had to do that before deploying an
application that mapped to one of them.
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. Tomcat and Jetty have different
capabilities, and there is a limit to which we can paper over them.
I don't think jetty has anything similar to valves, but if you try to
force this limitation on jetty I will propose eliminating valve
support for tomcat in geronimo as an analogous papering-over-action.
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.
How many unanticipated problems would this cause :-) ? Are there
other properties of the host we need to be able to set easily?
thanks
david jencks
Thanks,
Aaron
