geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Web container-specific configuration
Date Mon, 22 Aug 2005 23:50:25 GMT

On Aug 22, 2005, at 4:14 PM, Jeremy Boynes wrote:

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

Well, I've implemented it, and it works, which is more than the 
existing code, so I plan to commit it, if only to give people something 
concrete to argue against.

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

This will be true if we allow a "generic plan" in any form.  The only 
way to prevent it is to only allow jetty or tomcat namespaces, not the 
"generic" namespace.

I would be fine with that solution: I prefer that the plan namespace 
unambiguously identify what builder will be used.  However, I do not 
feel too strongly about it today, and I believe Aaron and Jeff strongly 
want "universal" plans.

> 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=""
>          configId="MyWebApp">
>     <some-generic-setting ... />
> </web-app>
> <web-app xmlns=""
>          xmlns:web=""
>          configId="MyWebAppOnJetty">
>     <web:some-generic-setting ... />
>     <jetty:some-jetty-setting ... />
> </web-app>
> <web-app xmlns=""
>          xmlns:web=""
>          configId="MyWebAppOnTomcat">
>     <web:some-generic-setting ... />
>     <tomcat:some-tomcat-setting ... />
> </web-app>

I don't see how to write schemas that these samples are valid for.  I 
think there might be a way to use substitution groups to do something 
like what you are suggesting, but I have never used them and don't know 
much about how they work.  Simple schema extension wont result in a 
usable schema IMO because the extension elements would have to go at 
the end, after the gbean definitions: this is not acceptable to me.

In any case, if we go toward this kind of solution, I believe we have 
to prohibit generic web plans to avoid the possibility of same input >> 
different output based on deployer configuration.

Again, I am (slightly) in favor of namespace >> builder and no generic 
web schema, but I am willing to accept the "any" configuration element 
solution I''m about to commit.  If we can agree on a namespace >> 
builder solution I'm happy to fix the schemas and builders to work that 
way, with as much schema inheritance as we can figure out how to 
include.  I'm not willing to accept the existing code with untyped 

david jencks

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

View raw message