geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: Web container-specific configuration
Date Mon, 22 Aug 2005 23:14:04 GMT
David Jencks wrote:
> After a lot of discussion about the virtual-host configuration, Aaron, 
> Jeff and I think that the best way to proceed is to have xml schemas for 
> container specific configuration and include the virtual host in the 
> container specific config.  This will replace the current name/property 
> container specific config.
> Why put the virtual host into container specific config?  well, the 
> meaning of specifying "virtual-host" in jetty and tomcat are really 
> different.  In tomcat this is a reference to a preconfigured list of 
> host + multiple aliases, and if will fail if the host is not already 
> configured.  In jetty, this simply adds the VH string to some routing 
> code inside jetty.  If we reused the same syntax for both containers, 
> you would get surprising results whenever you switched containers unless 
> you were very aware of the different meanings.
> How will the proposed container specific config work?  I'll add an any 
> element in the geronimo-web schema, and each builder will look for its 
> own namespace and interpret it as appropriate.  This will allow one plan 
> to be deployed on multiple web containers.
> comments?

I'd ask that we settle on something once and for all. This was changed 
once from container-specific to generic (breaking every existing plan), 
changed again to add in container-specific options, and now we're 
changing yet again having cut a release somewhere in the middle.

Before rushing to implementation, can we please put some more 
consideration and discussion into up-front design.

On the technical front, I remain uncomfortable with a single generic 
namespace as there is no way for the deployment system to tell what the 
target container will be. If the plan contains both Tomcat and Jetty 
configuration information, which one should the deployer pick as a 
target especially if it is capable of targeting both. Further, the 
output of deployment here cannot be determined using just the 
information in the plan - it also depends on which web-container builder 
gets loaded by the deployer. This means you can get different and 
incompatible output bundles with the same configId.

Rather than adding in extension elements, I think we should consider 
subclassing the generic schema for each container adding in as first 
class elements the items for that schema. We would then get something like:

<web-app xmlns=""

     <some-generic-setting ... />

<web-app xmlns=""

     <web:some-generic-setting ... />
     <jetty:some-jetty-setting ... />

<web-app xmlns=""

     <web:some-generic-setting ... />
     <tomcat:some-tomcat-setting ... />

The first would result in a configuration that could run on any web 
container, the last two would produce configurations that would run on a 
specific web container. Applications would typically use the first form 
unless they needed container-specific functionality (which would also 
mean that they needed that specific container at runtime).

I included the namespace qualifiers for clarity. I believe that suitable 
use of schema imports would mean that they could be removed simplifying 
the XML form used by users. It may be harder for us to implement, but I 
think ease-of-use is more important here than ease-of-implementation.


View raw message