On Aug 24, 2005, at 6:25 PM, Dain Sundstrom wrote:
On Aug 24, 2005, at 3:20 PM, David Jencks wrote:
While originally I thought having one schema with customization
elements for our many (currently 2) web containers was a great idea,
I have changed my mind and think that each web container should have
a separate namespace, although we should try to keep the schemas as
similar as possible. Let me try to explain why.
The basic principle is that the namespace should determine the
builder.
To implement this would require extensive modifications to the
current builder code, especially the earConfigBuilder. That is kind
of a minor point :-)
Lets imagine a server farm where 1000 are running jetty and 1000 are
running tomcat, but where for various reasons only binary
configurations can be deployed to the production servers: all
deployment to binary configurations occurs on a separate machine,
then the binary configurations are sent to the servers and started.
This is one of the big problems with processing a configuration on one
computer and deploying it on another. If you were to process a tomcat
configuration on you box and deploy it to a jetty server you will have
the same problem. Also, if you do not have an exact image of what is
running on the server the configuration won't even deserialize even if
it is using tomcat. As I see it the problem is "portable
configurations" simply don't work, not that we need to split our
common web configuration into two.
I have not experienced any evidence that versioned immutable
configurations don't work. I think our experience so far has been
entirely with unversioned configurations that change every 5 seconds.
Do you have any evidence that versioned binary configurations wouldn't
work?
If the namespace determines the builder and web container, then
deploying an app + plan is unambiguous: the builder chugs along, and
whenever if finds a new namespace in the plan it picks the builder
and tells it to get to work.
If we have something like we have now, where one namespace can apply
to one of several builders/containers, then we need more information,
such as a separate deployer configuration, to determine the proper
target and build the right configuration.
So, I'd like to move back to separate but equal schemas/namespaces
for jetty and tomcat plans.
Comments or objections?
We think should just have one simple standard web configuration file
to document and explain to our users. If you were proposing to just
use the native tomcat and jetty configuration file format that would
be one thing, but I just see this is just two *new* configuration file
formats for our users to learn. Let's keep it simple and stick to one
common configuration file.
With the current "any" solution, most tomcat configurations that
involve customizations would not be deployable on jetty, due to tomcat
specific gbeans. I think we can make a config file format that is
identical except for the namespace for simple apps, and has a more
natural format than the "any" config for server specific
customizations. I don't really see how asking people to use a jetty
specific or tomcat specific schema for the whole plan is all that
different from asking them to use jetty and tomcat specific schemas for
customization elements. I think it will be simpler for our users to
have one file mean one thing and for the vendor plan by itself to
determine what will be deployed. This may well mean including version
info for the parentId.
thanks
david jencks
-dain
