Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 41998 invoked from network); 25 Aug 2005 01:59:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 Aug 2005 01:59:08 -0000 Received: (qmail 24183 invoked by uid 500); 25 Aug 2005 01:59:06 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 24143 invoked by uid 500); 25 Aug 2005 01:59:06 -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 24130 invoked by uid 99); 25 Aug 2005 01:59:06 -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 18:59:06 -0700 X-ASF-Spam-Status: No, hits=0.4 required=10.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [216.136.174.140] (HELO smtp102.mail.sc5.yahoo.com) (216.136.174.140) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 24 Aug 2005 18:59:22 -0700 Received: (qmail 49007 invoked from network); 25 Aug 2005 01:59:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=dCjp0QvcBtaCo2J78E7hjJbQpf84ityasycjvhzbie5fNZxLAVDBwerPI/VA+571lzIbttBH5uXX7YagqGE8IFrQI4nCf34Pb1acm6cRHTv+KksFfAcyHjEhG2jI1c/zW2vty8UQTYoIrbkyiPZyoMVEaKoW7N/It2yo759VhCs= ; Received: from unknown (HELO ?192.168.1.105?) (david?jencks@66.93.38.137 with plain) by smtp102.mail.sc5.yahoo.com with SMTP; 25 Aug 2005 01:59:03 -0000 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <3cacb229dcd92ac303424f0b05bc6405@yahoo.com> References: <3cacb229dcd92ac303424f0b05bc6405@yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <39d96757738aa9c3b9f59cac2891ec92@yahoo.com> Content-Transfer-Encoding: 7bit From: David Jencks Subject: Re: Web schemas -- one or many? Date: Wed, 24 Aug 2005 18:59:02 -0700 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.622) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 >>> >>> >> >