You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2005/08/25 00:20:39 UTC
Web schemas -- one or many?
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.
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?
thanks
david jencks
Re: Web schemas -- one or many?
Posted by David Jencks <da...@yahoo.com>.
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
>
Re: Web schemas -- one or many?
Posted by Dain Sundstrom <da...@iq80.com>.
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
Re: Web schemas -- one or many?
Posted by David Jencks <da...@yahoo.com>.
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
>
Re: Web schemas -- one or many?
Posted by Dain Sundstrom <da...@iq80.com>.
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.
> 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.
-dain
Re: Web schemas -- one or many?
Posted by David Jencks <da...@yahoo.com>.
I should point out that more work is needed before my scenario is
realistic, including off the top of my head:
-- assembling the server from more smaller pieces, such as jetty and
tomcat configurations rather than the giant monolithic server
configuration we have now
-- different classloader structure such as OSGI like classloading where
your classloader includes classes from an essentially arbitrary set of
configurations.
-- versioned binary configurations
I would prefer to establish principles that would let us get to this
rosy future with few obstacles rather than do things that will
definitely conflict and need to be changed.
thanks
david jencks
On Aug 24, 2005, at 6:51 PM, David Jencks wrote:
> well, I am not that familiar with what people with large server farms
> actually do :-) I was thinking of something like an ISP offering
> geronimo hosting: you rent space and a geronimo instance on a box, but
> the deployment has to happen on a centralized deployment box. Either
> there is one centralized repo/box or the repo is over the network, so
> all server parts are available on all servers. In a couple of years,
> when we have 10 web containers and 5 ejb containers and 3 jca
> containers you will not want to set up the 150 deployment servers
> needed for all combinations. Here, clearly you would want the
> deployment plan to determine what you end up with, rather than the
> particular deployer configuration that happens to be available at the
> moment.
>
> In particular I'm thinking the same app would not be deployed on both
> jetty and tomcat very often.
>
> thanks
> david jencks
>
> On Aug 24, 2005, at 6:55 PM, Aaron Mulder wrote:
>
>> To pick one little nit, if you have 1000 Geronimo+Tomcat servers
>> and 1000 Geronimo+Jetty servers, surely it's in your best interest to
>> have
>> a Geronimo+Tomcat binary deployment environment and a Geronimo+Jetty
>> binary deployment environment. I don't understand why you'd go to
>> this
>> much trouble and then make your build server different than your
>> runtime
>> server (other than, of course, not having a runtime deployer).
>>
>> That being the case, wouldn't you be happer to have one version of
>> the application that you can build on the Jetty build box for all the
>> Jetty servers and that you can *also* build on the Tomcat build box
>> for
>> all the Tomcat servers? No chance that your Jetty copy of the
>> application
>> and your Tomcat copy of the application are out of sync?
>>
>> Aaron
>>
>> P.S. Is this even a realistic use case? Who is it that has a 2000
>> node
>> cluster with 1000 WebLogic boxes and 1000 Websphere boxes all running
>> the
>> same application?
>>
>> On Wed, 24 Aug 2005, 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.
>>>
>>> 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?
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>
>
Re: Web schemas -- one or many?
Posted by Dain Sundstrom <da...@iq80.com>.
On Aug 25, 2005, at 5:59 PM, Aaron Mulder wrote:
> On Thu, 25 Aug 2005, David Jencks wrote:
>
>> 1. Use the gbean.enabled attribute extensively and include both the
>> jetty and tomcat servers in the main config, with possibly one of
>> them
>> disabled: extend the config db so it can save the enabled/disabled
>> state. Then you can turn the one you want on or off.
>>
>
> I wasn't aware of such an attribute.
It is not an attribute. There are two methods on the kernel to
control the enabled flag:
/**
* Is the specified GBean enabled?
* @param name the name if the GBean
* @return true if the gbean is enabled
* @throws GBeanNotFoundException if the GBean could not be found
*/
boolean isGBeanEnabled(ObjectName name) throws
GBeanNotFoundException;
/**
* Sets the eneabled status of the specified GBean. A disabled
gbean can not be started, and
* will not be started via startRecursive.
* @param name the name if the GBean
* @param enabled the new enabled status
* @throws GBeanNotFoundException if the GBean could not be found
*/
void setGBeanEnabled(ObjectName name, boolean enabled) throws
GBeanNotFoundException;
> How does it work? Are
> "disabled" GBeans loaded but not started? Or not even loaded?
They are loaded but can not be started. If you want to start one you
have to reenable it.
> If they're loaded but not started, I'd like more detail on the
> start and stop behavior. For example, what happens if you go into the
> console and start the Tomcat container. Would all connectors and
> valves
> and tomcat realms and stuff be started, or would something have to
> separately start each and every one or them? Likewise for shutdown.
Um.. not sure what you are asking. If a service is disabled and you
try to start it, you get an IllegalStateException. If you call start
recursive on a parent service the service will not be started as part
of the recursion.
-dain
Re: Web schemas -- one or many?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Thu, 25 Aug 2005, David Jencks wrote:
> 1. Use the gbean.enabled attribute extensively and include both the
> jetty and tomcat servers in the main config, with possibly one of them
> disabled: extend the config db so it can save the enabled/disabled
> state. Then you can turn the one you want on or off.
I wasn't aware of such an attribute. How does it work? Are
"disabled" GBeans loaded but not started? Or not even loaded?
If they're loaded but not started, I'd like more detail on the
start and stop behavior. For example, what happens if you go into the
console and start the Tomcat container. Would all connectors and valves
and tomcat realms and stuff be started, or would something have to
separately start each and every one or them? Likewise for shutdown.
> 2. Write a delegating web deployer that has a default deployer, used
> for "no plan" and "generic plan": others it points to the correct
> deployer based on the namespace.
>
> Then we will need only one set of plans, and one assembly.
I'm happy-er with this proposal than the last one. In particular,
I like where you said everything currently in the generic plan plus single
virtual hosts would be handled by the common format.
The 3 formats for web plans still bothers me. I still like the
current solution of 1 plan with container-specific children. But I
would no longer say I'm "vehemently" opposed. :)
Aaron
Re: Web schemas -- one or many?
Posted by David Jencks <da...@yahoo.com>.
>
I'd like to throw more gasoline on this fire by extending my proposal
below:
1. Use the gbean.enabled attribute extensively and include both the
jetty and tomcat servers in the main config, with possibly one of them
disabled: extend the config db so it can save the enabled/disabled
state. Then you can turn the one you want on or off.
2. Write a delegating web deployer that has a default deployer, used
for "no plan" and "generic plan": others it points to the correct
deployer based on the namespace.
Then we will need only one set of plans, and one assembly.
thanks
david jencks
> <snip>
> So, I realize there is a bit of weakness in my idea, namely a lot of
> web apps don't need a plan: so in my rosy future, there would need to
> be a "default web container" that these would get pushed to. So, how
> about this idea:
>
> a "fake" common schema that includes the common elements and a single
> [virtual-]host element
> a jetty schema that is the same except allowing multiple virtual-host
> elements
> a tomcat schema that is the same but includes the additional tomcat
> specific elements.
>
> The tomcat and jetty builders can both change the common namespace to
> their own namespace and deploy as if it is their own.
>
> This takes care of 100% of the cases you mentioned :-) However, it
> doesn't take care of the <cross-context/> element which can be put in
> the tomcat config without making it undeployable on jetty. I'll
> actually weaken my case a bit by pointing out that the tomcat specific
> gbeans relating to the tomcat-realm and valve-chain should probably
> come from tomcat specific xml in the tomcat schema rather than plain
> gbean definitions.
>
> Could you live with this proposal?
>
> thanks
> david jencks
>
Re: Web schemas -- one or many?
Posted by Dain Sundstrom <da...@iq80.com>.
On Aug 25, 2005, at 4:05 PM, David Jencks wrote:
>
> On Aug 25, 2005, at 3:51 PM, Dain Sundstrom wrote:
>
>
>> On Aug 24, 2005, at 8:55 PM, David Jencks wrote:
>>
>>
>>> So, I realize there is a bit of weakness in my idea, namely a lot
>>> of web apps don't need a plan: so in my rosy future, there would
>>> need to be a "default web container" that these would get pushed
>>> to. So, how about this idea:
>>>
>>> a "fake" common schema that includes the common elements and a
>>> single [virtual-]host element
>>> a jetty schema that is the same except allowing multiple virtual-
>>> host elements
>>> a tomcat schema that is the same but includes the additional
>>> tomcat specific elements.
>>>
>>> The tomcat and jetty builders can both change the common
>>> namespace to their own namespace and deploy as if it is their own.
>>>
>>> This takes care of 100% of the cases you mentioned :-) However,
>>> it doesn't take care of the <cross-context/> element which can be
>>> put in the tomcat config without making it undeployable on
>>> jetty. I'll actually weaken my case a bit by pointing out that
>>> the tomcat specific gbeans relating to the tomcat-realm and valve-
>>> chain should probably come from tomcat specific xml in the tomcat
>>> schema rather than plain gbean definitions.
>>>
>>> Could you live with this proposal?
>>>
>>
>> Are you proposing that we support 3 configuration file formats:
>> geronimo-web.xml, geronimo-jetty.xml, and geronimo-tomcat.xml?
>>
>
> yes. Also, a valid geronimo-web document is a valid geronimo-jetty
> or geronimo-tomcat document after changng the namespace.
I don't like this. This is killing the user with options. Can't we
just come up with a single reasonable format with escapes for the
rare cases?
-dain
Re: Web schemas -- one or many?
Posted by David Jencks <da...@yahoo.com>.
On Aug 25, 2005, at 3:51 PM, Dain Sundstrom wrote:
> On Aug 24, 2005, at 8:55 PM, David Jencks wrote:
>
>> So, I realize there is a bit of weakness in my idea, namely a lot of
>> web apps don't need a plan: so in my rosy future, there would need to
>> be a "default web container" that these would get pushed to. So, how
>> about this idea:
>>
>> a "fake" common schema that includes the common elements and a single
>> [virtual-]host element
>> a jetty schema that is the same except allowing multiple virtual-host
>> elements
>> a tomcat schema that is the same but includes the additional tomcat
>> specific elements.
>>
>> The tomcat and jetty builders can both change the common namespace to
>> their own namespace and deploy as if it is their own.
>>
>> This takes care of 100% of the cases you mentioned :-) However, it
>> doesn't take care of the <cross-context/> element which can be put in
>> the tomcat config without making it undeployable on jetty. I'll
>> actually weaken my case a bit by pointing out that the tomcat
>> specific gbeans relating to the tomcat-realm and valve-chain should
>> probably come from tomcat specific xml in the tomcat schema rather
>> than plain gbean definitions.
>>
>> Could you live with this proposal?
>
> Are you proposing that we support 3 configuration file formats:
> geronimo-web.xml, geronimo-jetty.xml, and geronimo-tomcat.xml?
yes. Also, a valid geronimo-web document is a valid geronimo-jetty or
geronimo-tomcat document after changng the namespace.
david jencks
>
> -dain
>
Re: Web schemas -- one or many?
Posted by Dain Sundstrom <da...@iq80.com>.
On Aug 24, 2005, at 8:55 PM, David Jencks wrote:
> So, I realize there is a bit of weakness in my idea, namely a lot
> of web apps don't need a plan: so in my rosy future, there would
> need to be a "default web container" that these would get pushed
> to. So, how about this idea:
>
> a "fake" common schema that includes the common elements and a
> single [virtual-]host element
> a jetty schema that is the same except allowing multiple virtual-
> host elements
> a tomcat schema that is the same but includes the additional tomcat
> specific elements.
>
> The tomcat and jetty builders can both change the common namespace
> to their own namespace and deploy as if it is their own.
>
> This takes care of 100% of the cases you mentioned :-) However, it
> doesn't take care of the <cross-context/> element which can be put
> in the tomcat config without making it undeployable on jetty. I'll
> actually weaken my case a bit by pointing out that the tomcat
> specific gbeans relating to the tomcat-realm and valve-chain should
> probably come from tomcat specific xml in the tomcat schema rather
> than plain gbean definitions.
>
> Could you live with this proposal?
Are you proposing that we support 3 configuration file formats:
geronimo-web.xml, geronimo-jetty.xml, and geronimo-tomcat.xml?
-dain
Re: Web schemas -- one or many?
Posted by David Jencks <da...@yahoo.com>.
On Aug 24, 2005, at 7:54 PM, Aaron Mulder wrote:
> On Wed, 24 Aug 2005, David Jencks wrote:
>> well, I am not that familiar with what people with large server farms
>> actually do :-) I was thinking of something like an ISP offering
>> geronimo hosting: you rent space and a geronimo instance on a box, but
>> the deployment has to happen on a centralized deployment box.
>
> I have (like today, IRL) an ISP account with Tomcat hosting. The
> account has a Tomcat directory in it, and I can do whatever I want to
> webapps/ under there. Where it usually takes 30 minutes just to get an
> e-mail response from the ISP's support desk. I don't think your
> scenario
> is plausible for ISPs since they won't need to deploy the same app to
> numerous boxes, and the ISP doesn't want to incur extra work for their
> own
> staff every time some wacky customer wants to push a trivial change to
> their own web site (which is just 1 node among thousands, so
> pre-building
> elsewhere didn't get you anything).
>
> I think the 1000-runtime-1-deployer scenario would be much more
> plausable for Ebay or Amazon something -- a corporation with 1 app and
> a
> giant web presence. And again, I don't see any reason for them to run
> half Tomcat and half Jetty.
>
>> Either there is one centralized repo/box or the repo is over the
>> network, so all server parts are available on all servers. In a
>> couple
>> of years, when we have 10 web containers and 5 ejb containers and 3
>> jca
>> containers you will not want to set up the 150 deployment servers
>> needed
>> for all combinations.
>
> First of all, I'm going to be in jail for strangling someone long
> before we get to that level of variety. Either that, or the very
> successful CEO of a company that offers preciely 1 configuration and
> let
> you open source bozos do what you please. :) Are you actually
> suggesting
> with a straight face that we run the TCK 150 times before every
> release?
> I think we're well past ridiculous now and into delusional.
>
>> Here, clearly you would want the deployment plan to determine what you
>> end up with, rather than the particular deployer configuration that
>> happens to be available at the moment.
>
> I'm still dazed by this 150-configuration scenario. You want a
> single build box with 10 web containers, 5 EJB containers, and 3 JCA
> containers, so you can build an app there for your cluster of 1000
> "identical" machines, then push it to your work nodes where it
> successfully deploys to less than 1% of them?
Any app would run on any of the machines -- the dependencies would
start whatever server parts are needed to run the app. Basically you'd
have a kernel sitting there, and an app with a jetty plan would have a
dependency on the jetty server configuration, so loading the
configuration would load jetty too.
>
> I need a visual for this -- I'm making the little
> thumb-and-forefinger sign for "pass the joint" at you. :)
Ok, after enjoying the rest of the imaginary joint you passed to me
:-)... very refreshing ....
>
>> In particular I'm thinking the same app would not be deployed on both
>> jetty and tomcat very often.
>
> OK, this we can have an intelligent debate about. I believe that
> the functional differences between Tomcat and Jetty are small enough
> that
> it doesn't make a whole lot of difference which one you deploy to, for
> the
> majority of applications. (Granted not true if you rely on Tomcat
> Valves,
> but I don't consider that to be the majority of web apps.) That being
> the
> case, I as an application developer would always opt for portability,
> and
> create an app that works in both. 99% of the time that will mean (for
> me,
> at present) writing one geronimo-web.xml with no Jetty or Tomcat
> content.
> In that other 1% of cases I need the ability to specify a (single)
> virtual
> host, which I can do in both Tomcat and Jetty but slightly
> differently, so
> I'd have a geronimo-web.xml with a 1-setting Tomcat block and a
> 1-setting
> Jetty block, and then my app still supports both.
>
> Let me put it this way. If there was one deployment plan format
> you could use that would make your web app work in Geronimo, Tomcat,
> Jetty, JBoss, Weblogic, and Websphere, would you use it? I sure would.
> Portability and flexibility is a great thing. Sure, I don't feel the
> urge
> to write 7 plans for the apps I work with today, so it's not like
> that's a
> critical feature. But we have something that makes the majority of
> applications work perfectly across both configurations of Geronimo that
> it's possible for someone to have, and you're suggesting we break that
> and
> make every web app fail automatically in 50% of Geronimo installations.
> I think that's a definite move in the wrong direction.
So, I realize there is a bit of weakness in my idea, namely a lot of
web apps don't need a plan: so in my rosy future, there would need to
be a "default web container" that these would get pushed to. So, how
about this idea:
a "fake" common schema that includes the common elements and a single
[virtual-]host element
a jetty schema that is the same except allowing multiple virtual-host
elements
a tomcat schema that is the same but includes the additional tomcat
specific elements.
The tomcat and jetty builders can both change the common namespace to
their own namespace and deploy as if it is their own.
This takes care of 100% of the cases you mentioned :-) However, it
doesn't take care of the <cross-context/> element which can be put in
the tomcat config without making it undeployable on jetty. I'll
actually weaken my case a bit by pointing out that the tomcat specific
gbeans relating to the tomcat-realm and valve-chain should probably
come from tomcat specific xml in the tomcat schema rather than plain
gbean definitions.
Could you live with this proposal?
thanks
david jencks
>
> Aaron
>
>
>> On Aug 24, 2005, at 6:55 PM, Aaron Mulder wrote:
>>
>>> To pick one little nit, if you have 1000 Geronimo+Tomcat servers
>>> and 1000 Geronimo+Jetty servers, surely it's in your best interest to
>>> have
>>> a Geronimo+Tomcat binary deployment environment and a Geronimo+Jetty
>>> binary deployment environment. I don't understand why you'd go to
>>> this
>>> much trouble and then make your build server different than your
>>> runtime
>>> server (other than, of course, not having a runtime deployer).
>>>
>>> That being the case, wouldn't you be happer to have one version of
>>> the application that you can build on the Jetty build box for all the
>>> Jetty servers and that you can *also* build on the Tomcat build box
>>> for
>>> all the Tomcat servers? No chance that your Jetty copy of the
>>> application
>>> and your Tomcat copy of the application are out of sync?
>>>
>>> Aaron
>>>
>>> P.S. Is this even a realistic use case? Who is it that has a 2000
>>> node
>>> cluster with 1000 WebLogic boxes and 1000 Websphere boxes all running
>>> the
>>> same application?
>>>
>>> On Wed, 24 Aug 2005, 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.
>>>>
>>>> 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?
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>
>>
>>
>
Re: Web schemas -- one or many?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Wed, 24 Aug 2005, David Jencks wrote:
> well, I am not that familiar with what people with large server farms
> actually do :-) I was thinking of something like an ISP offering
> geronimo hosting: you rent space and a geronimo instance on a box, but
> the deployment has to happen on a centralized deployment box.
I have (like today, IRL) an ISP account with Tomcat hosting. The
account has a Tomcat directory in it, and I can do whatever I want to
webapps/ under there. Where it usually takes 30 minutes just to get an
e-mail response from the ISP's support desk. I don't think your scenario
is plausible for ISPs since they won't need to deploy the same app to
numerous boxes, and the ISP doesn't want to incur extra work for their own
staff every time some wacky customer wants to push a trivial change to
their own web site (which is just 1 node among thousands, so pre-building
elsewhere didn't get you anything).
I think the 1000-runtime-1-deployer scenario would be much more
plausable for Ebay or Amazon something -- a corporation with 1 app and a
giant web presence. And again, I don't see any reason for them to run
half Tomcat and half Jetty.
> Either there is one centralized repo/box or the repo is over the
> network, so all server parts are available on all servers. In a couple
> of years, when we have 10 web containers and 5 ejb containers and 3 jca
> containers you will not want to set up the 150 deployment servers needed
> for all combinations.
First of all, I'm going to be in jail for strangling someone long
before we get to that level of variety. Either that, or the very
successful CEO of a company that offers preciely 1 configuration and let
you open source bozos do what you please. :) Are you actually suggesting
with a straight face that we run the TCK 150 times before every release?
I think we're well past ridiculous now and into delusional.
> Here, clearly you would want the deployment plan to determine what you
> end up with, rather than the particular deployer configuration that
> happens to be available at the moment.
I'm still dazed by this 150-configuration scenario. You want a
single build box with 10 web containers, 5 EJB containers, and 3 JCA
containers, so you can build an app there for your cluster of 1000
"identical" machines, then push it to your work nodes where it
successfully deploys to less than 1% of them?
I need a visual for this -- I'm making the little
thumb-and-forefinger sign for "pass the joint" at you. :)
> In particular I'm thinking the same app would not be deployed on both
> jetty and tomcat very often.
OK, this we can have an intelligent debate about. I believe that
the functional differences between Tomcat and Jetty are small enough that
it doesn't make a whole lot of difference which one you deploy to, for the
majority of applications. (Granted not true if you rely on Tomcat Valves,
but I don't consider that to be the majority of web apps.) That being the
case, I as an application developer would always opt for portability, and
create an app that works in both. 99% of the time that will mean (for me,
at present) writing one geronimo-web.xml with no Jetty or Tomcat content.
In that other 1% of cases I need the ability to specify a (single) virtual
host, which I can do in both Tomcat and Jetty but slightly differently, so
I'd have a geronimo-web.xml with a 1-setting Tomcat block and a 1-setting
Jetty block, and then my app still supports both.
Let me put it this way. If there was one deployment plan format
you could use that would make your web app work in Geronimo, Tomcat,
Jetty, JBoss, Weblogic, and Websphere, would you use it? I sure would.
Portability and flexibility is a great thing. Sure, I don't feel the urge
to write 7 plans for the apps I work with today, so it's not like that's a
critical feature. But we have something that makes the majority of
applications work perfectly across both configurations of Geronimo that
it's possible for someone to have, and you're suggesting we break that and
make every web app fail automatically in 50% of Geronimo installations.
I think that's a definite move in the wrong direction.
Aaron
> On Aug 24, 2005, at 6:55 PM, Aaron Mulder wrote:
>
> > To pick one little nit, if you have 1000 Geronimo+Tomcat servers
> > and 1000 Geronimo+Jetty servers, surely it's in your best interest to
> > have
> > a Geronimo+Tomcat binary deployment environment and a Geronimo+Jetty
> > binary deployment environment. I don't understand why you'd go to this
> > much trouble and then make your build server different than your
> > runtime
> > server (other than, of course, not having a runtime deployer).
> >
> > That being the case, wouldn't you be happer to have one version of
> > the application that you can build on the Jetty build box for all the
> > Jetty servers and that you can *also* build on the Tomcat build box for
> > all the Tomcat servers? No chance that your Jetty copy of the
> > application
> > and your Tomcat copy of the application are out of sync?
> >
> > Aaron
> >
> > P.S. Is this even a realistic use case? Who is it that has a 2000 node
> > cluster with 1000 WebLogic boxes and 1000 Websphere boxes all running
> > the
> > same application?
> >
> > On Wed, 24 Aug 2005, 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.
> >>
> >> 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?
> >>
> >> thanks
> >> david jencks
> >>
> >>
> >
>
>
Re: Web schemas -- one or many?
Posted by David Jencks <da...@yahoo.com>.
well, I am not that familiar with what people with large server farms
actually do :-) I was thinking of something like an ISP offering
geronimo hosting: you rent space and a geronimo instance on a box, but
the deployment has to happen on a centralized deployment box. Either
there is one centralized repo/box or the repo is over the network, so
all server parts are available on all servers. In a couple of years,
when we have 10 web containers and 5 ejb containers and 3 jca
containers you will not want to set up the 150 deployment servers
needed for all combinations. Here, clearly you would want the
deployment plan to determine what you end up with, rather than the
particular deployer configuration that happens to be available at the
moment.
In particular I'm thinking the same app would not be deployed on both
jetty and tomcat very often.
thanks
david jencks
On Aug 24, 2005, at 6:55 PM, Aaron Mulder wrote:
> To pick one little nit, if you have 1000 Geronimo+Tomcat servers
> and 1000 Geronimo+Jetty servers, surely it's in your best interest to
> have
> a Geronimo+Tomcat binary deployment environment and a Geronimo+Jetty
> binary deployment environment. I don't understand why you'd go to this
> much trouble and then make your build server different than your
> runtime
> server (other than, of course, not having a runtime deployer).
>
> That being the case, wouldn't you be happer to have one version of
> the application that you can build on the Jetty build box for all the
> Jetty servers and that you can *also* build on the Tomcat build box for
> all the Tomcat servers? No chance that your Jetty copy of the
> application
> and your Tomcat copy of the application are out of sync?
>
> Aaron
>
> P.S. Is this even a realistic use case? Who is it that has a 2000 node
> cluster with 1000 WebLogic boxes and 1000 Websphere boxes all running
> the
> same application?
>
> On Wed, 24 Aug 2005, 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.
>>
>> 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?
>>
>> thanks
>> david jencks
>>
>>
>
Re: Web schemas -- one or many?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
To pick one little nit, if you have 1000 Geronimo+Tomcat servers
and 1000 Geronimo+Jetty servers, surely it's in your best interest to have
a Geronimo+Tomcat binary deployment environment and a Geronimo+Jetty
binary deployment environment. I don't understand why you'd go to this
much trouble and then make your build server different than your runtime
server (other than, of course, not having a runtime deployer).
That being the case, wouldn't you be happer to have one version of
the application that you can build on the Jetty build box for all the
Jetty servers and that you can *also* build on the Tomcat build box for
all the Tomcat servers? No chance that your Jetty copy of the application
and your Tomcat copy of the application are out of sync?
Aaron
P.S. Is this even a realistic use case? Who is it that has a 2000 node
cluster with 1000 WebLogic boxes and 1000 Websphere boxes all running the
same application?
On Wed, 24 Aug 2005, 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.
>
> 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?
>
> thanks
> david jencks
>
>