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="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>
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
extensions.
thanks
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
