On Aug 24, 2005, at 6:38 PM, David Jencks wrote:
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?
Yes. I build a configuration on my mac laptop, and push it to a
windows box for TCK testing. The windows box has a different version
of the OpenEJB jar, so the configurations won't deserialize. I
consider myself a fairly savvy user, and most trivial changes I
assumed would work in a any other server have surprising consequences
in Geronimo. The most glowing example is attempting to push a
patched jar to the server, which results in object serialization
errors. This means that for a user to test a fix they need to
install a new server, reconfigure the server, and reinstall all
applications.
-dain
