On Aug 24, 2005, at 7:10 PM, Dain Sundstrom wrote:
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.
AFAICT, our binary configurations are currently unversioned, so I'm not
sure how you can come to any conclusions about versioned configurations
from geronimo. Could you explain?
thanks
david jencks
-dain
