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="http://geronimo.apache.org/xml/ns/web";
configId="MyWebApp">
<some-generic-setting ... />
</web-app>
<web-app xmlns="http://geronimo.apache.org/xml/ns/web/jetty";
xmlns:web="http://geronimo.apache.org/xml/ns/web";
configId="MyWebAppOnJetty">
<web:some-generic-setting ... />
<jetty:some-jetty-setting ... />
</web-app>
<web-app xmlns="http://geronimo.apache.org/xml/ns/web/tomcat";
xmlns:web="http://geronimo.apache.org/xml/ns/web";
configId="MyWebAppOnTomcat">
<web:some-generic-setting ... />
<tomcat:some-tomcat-setting ... />
</web-app>
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
