Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 50860 invoked from network); 25 Aug 2005 02:39:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 Aug 2005 02:39:02 -0000 Received: (qmail 59630 invoked by uid 500); 25 Aug 2005 02:38:55 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 59589 invoked by uid 500); 25 Aug 2005 02:38:54 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 59576 invoked by uid 99); 25 Aug 2005 02:38:54 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Aug 2005 19:38:54 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [66.250.40.202] (HELO saturn.opentools.org) (66.250.40.202) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Aug 2005 19:39:12 -0700 Received: by saturn.opentools.org (Postfix, from userid 500) id BD05D3F98; Wed, 24 Aug 2005 22:54:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by saturn.opentools.org (Postfix) with ESMTP id B6590F3A9 for ; Wed, 24 Aug 2005 22:54:58 -0400 (EDT) Date: Wed, 24 Aug 2005 22:54:58 -0400 (EDT) From: Aaron Mulder X-X-Sender: ammulder@saturn.opentools.org To: dev@geronimo.apache.org Subject: Re: Web schemas -- one or many? In-Reply-To: <3cacb229dcd92ac303424f0b05bc6405@yahoo.com> Message-ID: References: <3cacb229dcd92ac303424f0b05bc6405@yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 > >> > >> > > > >