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 22:06:02 GMT

On Jan 16, 2006, at 1:07 PM, Aaron Mulder wrote:

> On 1/16/06, David Jencks <> 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?

david jencks

> Thanks,
>     Aaron

View raw message