geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Web schemas -- one or many?
Date Thu, 25 Aug 2005 01:38:36 GMT

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
>


Mime
View raw message