Return-Path: 
 <dev-return-16112-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org>
Delivered-To: apmail-geronimo-dev-archive@www.apache.org
Received: (qmail 11353 invoked from network); 25 Aug 2005 22:53:53 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 25 Aug 2005 22:53:53 -0000
Received: (qmail 77462 invoked by uid 500); 25 Aug 2005 22:53:51 -0000
Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org
Received: (qmail 77172 invoked by uid 500); 25 Aug 2005 22:53:49 -0000
Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@geronimo.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@geronimo.apache.org>
List-Post: <mailto:dev@geronimo.apache.org>
Reply-To: dev@geronimo.apache.org
List-Id: <dev.geronimo.apache.org>
Delivered-To: mailing list dev@geronimo.apache.org
Received: (qmail 77158 invoked by uid 99); 25 Aug 2005 22:53:49 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Aug 2005 15:53:49 -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 [66.163.169.225] (HELO smtp105.mail.sc5.yahoo.com)
 (66.163.169.225)
    by apache.org (qpsmtpd/0.29) with SMTP; Thu, 25 Aug 2005 15:54:06 -0700
Received: (qmail 68205 invoked from network); 25 Aug 2005 22:53:47 -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=BXuyy2pmgFu2TIOxAoFy0S+poRtqC+4ptd/jPDc/eqeEfrEks7/S6otzVGsfIbcO3yXFFdNJSpKGvmOVpNLHpoinPctR3Ah6VAPguuSmDwaMiewkIHlDV2Rkb7QnfLdTn1TPi2C5cy8iIFgSn3KGIxdV2AJUaW1LJIkwY2N33ac=
  ;
Received: from unknown (HELO ?192.168.1.105?) (david?jencks@66.93.38.137 with
 plain)
  by smtp105.mail.sc5.yahoo.com with SMTP; 25 Aug 2005 22:53:47 -0000
Mime-Version: 1.0 (Apple Message framework v622)
In-Reply-To: <e9140c52a282f970a22c49bd0902247b@yahoo.com>
References: <d076f9f6e150adf5c7f95180b8a7f20e@yahoo.com>
 <Pine.LNX.4.58.0508242148500.21685@saturn.opentools.org>
 <3cacb229dcd92ac303424f0b05bc6405@yahoo.com>
 <Pine.LNX.4.58.0508242229170.21685@saturn.opentools.org>
 <e9140c52a282f970a22c49bd0902247b@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6a659fa1bbcebc13b7bf41bade022672@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: Web schemas -- one or many?
Date: Thu, 25 Aug 2005 15:53:42 -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'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
>