Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 61401 invoked from network); 20 May 2009 15:27:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 20 May 2009 15:27:29 -0000 Received: (qmail 90312 invoked by uid 500); 20 May 2009 15:27:41 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 90238 invoked by uid 500); 20 May 2009 15:27:41 -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 90230 invoked by uid 99); 20 May 2009 15:27:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 May 2009 15:27:41 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of greensight@gmail.com designates 209.85.217.166 as permitted sender) Received: from [209.85.217.166] (HELO mail-gx0-f166.google.com) (209.85.217.166) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 May 2009 15:27:33 +0000 Received: by gxk10 with SMTP id 10so1001300gxk.19 for ; Wed, 20 May 2009 08:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=O76n/y2U6acEymzExX0lVvKDQw+35gbc1HWwomla56U=; b=cD484F2Q8cic4XujtHoj8mvPGfzm0J2rpeys/rRasRvw56JOXsSyeynhmMGamx+GW/ ynfUlHlLzYbLGaXsbYZag7t2pTIiUjV1CR/OFX4ZMVjhYSlSj2c9G/E5d+JRbF3W+ds7 64AtqwREnWAnWMw2eIH5RhRbfKJOzR3Xm6+v0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=RyZ3/W6ie6Y/gr1R80Nvi0q/Qm34GaAvzloT1eF1/62MTYjavhNrwunNWjONid3ZTo V+7+3Rw0HS5LTKT2ZyiAKFq3qBk/WwzQETr53CBV2MUndpzq/rdYGu/p+QSPksDVQX4l GqosXcbdk9B2pkiXYsX5A9GUm3lQQrA/um64E= MIME-Version: 1.0 Received: by 10.151.12.12 with SMTP id p12mr2974841ybi.39.1242833232564; Wed, 20 May 2009 08:27:12 -0700 (PDT) In-Reply-To: <45f744e40905200744s42b19216w1f5f667eca1dab56@mail.gmail.com> References: <4A11BBDB.1010101@gmail.com> <4A130BBB.1070600@gmail.com> <2CA7113E-6C65-4B44-8F53-8A4651E3EDCD@yahoo.com> <45f744e40905200744s42b19216w1f5f667eca1dab56@mail.gmail.com> Date: Wed, 20 May 2009 23:27:12 +0800 Message-ID: <5e7fd1eb0905200827n27cafef9gcb4469aab169c707@mail.gmail.com> Subject: Re: Possible for G to directly consume a Tomcat server config w/o changes? From: Jack Cai To: dev@geronimo.apache.org Content-Type: multipart/alternative; boundary=000e0cd6a90e5794c4046a59a9d2 X-Virus-Checked: Checked by ClamAV on apache.org --000e0cd6a90e5794c4046a59a9d2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Agree that we won't contain this in G 2.2, but it might be a candidate feature for futher release like JEE6 Web Profile. Importing Tomcat server configs is relatively easier than importing Tomcat applications. If we consider an application which uses Struts, Hibernate, Spring, AXIS2 etc. (which is quite common), things becomes much complex. Still, doable, but not a trivial work. -Jack 2009/5/20 Ivan > I guess that what David means is that writing a deployer for server.xml, > then in the builder class, construct those tomcat server gbeans, and add > those gbeans to the tomcat plugin section in the config.xml. So that we > could imitate a totally same tomcat environment for those tomcat-ready > applications. > Right ? > Ivan > > 2009/5/20 Lin Sun > > One example that we did this is with the config-substitution property >> file where we allow users to specify configuration and the server >> reads the config-substitution property file during the startup of the >> server. If we more or less freeze the configuration, wouldn't this >> (reading data from server.xml and build the tomcat plugin) have to be >> done at the build time when we build the geronimo plugin for tomcat >> using maven2? I think the user would want to do this at runtime >> where the geronimo server is already prebuilt. >> >> On Wed, May 20, 2009 at 3:16 AM, David Jencks >> wrote: >> >> > I'm not sure about this idea. It seems really contrary to how most of >> > geronimo works.... where we take some kind of plan and more or less >> freeze >> > the configuration while "pre-deploying" it into a pretty much immutable >> > plugin. I'm not convinced that accepting a new kind of plan for a few >> > gbeans requires adding this "continual redeploy" functionality to >> geronimo. >> > >> >> >> >> 3. During G startup, G can just build the embedded tomcat server by >> >> reading data from config.xml, like what it is doing today. >> > >> > config.xml doesn't have to contain any info on the tomcat server except >> that >> > it ought to be started, i.e. listing the plugin. The gbean >> configurations >> > are all serialized in the plugin. I'd generally prefer it if we dropped >> the >> > ability to add gbeans to a plugin via config.xml. >> >> Again, this may be something that I don't understand well. If we >> don't configure it in config.xml, how do we allow users to drop in >> their tomcat server.xml without rebuilding the tomcat plugin? >> >> >> >> >> AFAIK, server.xml doesn't contain any app info. I agree that this is >> >> a very big change and requires a lot of testing to make sure things >> >> are not regressed. >> > >> > Adding this new namespace driven builder is entirely new functionality >> so >> > there is not really any chance of regressions unless we decide to deploy >> the >> > "standard" tomcat server this way, which is certainly not necessary to >> > adding the feature. So, to me the only problems are actually writing >> the >> > deployer and making sure it at least sort of works. >> >> To me, anything that has been changed needs to be tested somehow :) >> Regarding writing the deployer, I assume you meant the ability for G >> to deploy tomcat ready web archives. I think this can involve a >> large number of work, basically, we have to be able to generate >> geronimo-web.xml for the user's web archives, and deploy the web >> archive using the generated geronimo-web.xml file. >> >> Lin >> > > > > -- > Ivan > --000e0cd6a90e5794c4046a59a9d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agree that we won't contain this in G 2.2, but it might be a candidate = feature for futher release like JEE6 Web Profile.

Importing Tomcat s= erver configs is relatively easier than importing Tomcat applications. If w= e consider an application which uses Struts, Hibernate, Spring, AXIS2 etc. = (which is quite common), things becomes much complex. Still, doable, but no= t a trivial work.

-Jack

2009/5/20 Ivan <xhhsld@gmail.com>
I guess that what David means is that writing a deployer for server.xml, th= en in the builder class, construct those tomcat server gbeans, and add thos= e gbeans to the tomcat plugin section in the config.xml. So that we could i= mitate a totally same tomcat environment for those tomcat-ready application= s.
Right ?
=A0=A0=A0 Ivan

2009/5/20 Lin S= un <linsun.unc@gmail.com>

One example that we did this is with the config-substitution property
file where we allow users to specify configuration and the server
reads the config-substitution property file during the startup of the
server. =A0 If we more or less freeze the configuration, wouldn't this<= br> (reading data from server.xml and build the tomcat plugin) have to be
done at the build time when we build the geronimo plugin for tomcat
using maven2? =A0 =A0I think the user would want to do this at runtime
where the geronimo server is already prebuilt.

On Wed, May 20, 2009 at 3:16 AM, David Jencks <david_jencks@yahoo.com> wrote:
> I'm not sure about this idea. =A0It seems really contrary to how m= ost of
> geronimo works.... where we take some kind of plan and more or less fr= eeze
> the configuration while "pre-deploying" it into a pretty muc= h immutable
> plugin. =A0I'm not convinced that accepting a new kind of plan for= a few
> gbeans requires adding this "continual redeploy" functionali= ty to geronimo.
>
>>
>> 3. During G startup, G can just build the embedded tomcat server b= y
>> reading data from config.xml, like what it is doing today.
>
> config.xml doesn't have to contain any info on the tomcat server e= xcept that
> it ought to be started, i.e. listing the plugin. =A0The gbean configur= ations
> are all serialized in the plugin. =A0I'd generally prefer it if we= dropped the
> ability to add gbeans to a plugin via config.xml.

Again, this may be something that I don't understand well. =A0If = we
don't configure it in config.xml, how do we allow users to drop in
their tomcat server.xml without rebuilding the tomcat plugin?

>>
>> AFAIK, server.xml doesn't contain any app info. =A0 I agree th= at this is
>> a very big change and requires a lot of testing to make sure thing= s
>> are not regressed.
>
> Adding this new namespace driven builder is entirely new functionality= so
> there is not really any chance of regressions unless we decide to depl= oy the
> "standard" tomcat server this way, which is certainly not ne= cessary to
> adding the feature. =A0So, to me the only problems are actually writin= g the
> deployer and making sure it at least sort of works.

To me, anything that has been changed needs to be tested somehow :) Regarding writing the deployer, I assume you meant the ability for G
to deploy tomcat ready web archives. =A0 I think this can involve a
large number of work, basically, we have to be able to generate
geronimo-web.xml for the user's web archives, and deploy the web
archive using the generated geronimo-web.xml file.

Lin



--
Ivan

--000e0cd6a90e5794c4046a59a9d2--