Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 82750 invoked from network); 19 May 2009 22:09:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 19 May 2009 22:09:27 -0000 Received: (qmail 35398 invoked by uid 500); 19 May 2009 22:09:40 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 35322 invoked by uid 500); 19 May 2009 22:09:40 -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 35314 invoked by uid 99); 19 May 2009 22:09:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 May 2009 22:09:40 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=SPF_PASS,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [98.136.44.62] (HELO smtp107.prem.mail.sp1.yahoo.com) (98.136.44.62) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 19 May 2009 22:09:29 +0000 Received: (qmail 426 invoked from network); 19 May 2009 22:09:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=rVtt0xl4pUOHr80QlykmAh96q0j9BCUVJZuhkcuiC/nW7G9hu7h2pu64EjVp0FOS7iJ3EMjCg7/j8GgVOkhimcYCK1XBP7wqztMKIEGhnNAIlqg+xyWD6fdN1D68HlUZdaKHHT85wHKerXbPdGJC99jH4Ka/FPb49ENLj00tTXI= ; Received: from 076-076-148-215.pdx.net (david_jencks@76.76.148.215 with plain) by smtp107.prem.mail.sp1.yahoo.com with SMTP; 19 May 2009 15:09:07 -0700 PDT X-Yahoo-SMTP: .9oIUzyswBANsYgUm_5uPui0skTnzGJXJQ-- X-YMail-OSG: gDe4ScAVM1l4kI1hIIkk.HJ9VQP4q.9MNFXL67v.cVXmqmOH_OXUtlV_PQurr7Y0ddopGMMV02hDBR6a9eMcvdXLMBwVlDNhCfgG.d8Aw.5saiZ31pS9SMCrMQghopMAKIRYjEU_ZI0lgxaoTM.mmx4oTTyCs3bJXXFkWl0etLAsewmqVj5J7KuVGDsffl24S9LgR.ztvcYzggiuwY11x_KsQ.elUUYcOluFn0CRfRnjMXVfhOue5EwaOTlFg_GWpVd3vgG9y.L.JlDbQU7fYwDMMh1s7ibr8OTgBKXzpkuyKQtIivyTs2OUq4R6hUGAcZDgyerYAXfE79UEMQmo X-Yahoo-Newman-Property: ymail-3 Message-Id: <2CA7113E-6C65-4B44-8F53-8A4651E3EDCD@yahoo.com> From: David Jencks To: dev@geronimo.apache.org In-Reply-To: <4A130BBB.1070600@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Possible for G to directly consume a Tomcat server config w/o changes? Date: Tue, 19 May 2009 15:09:06 -0700 References: <4A11BBDB.1010101@gmail.com> <4A130BBB.1070600@gmail.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org On May 19, 2009, at 12:42 PM, Bill Stoddard wrote: > Lin Sun wrote: >> One quick way would be allow users to start a tomcat server from a >> geronimo tomcat javaee5 assembly or little G tomcat assembly(say >> geronimo.sh start tomcatOnly=true). It is possible to just launch >> the tomcat server, and read the configuration files (conf/server.xml, >> etc) and start a tomcat server from a geronimo tomcat assembly, by >> using the Catalina.java provided by tomcat. But this server/app >> would have no relationship with geronimo, other than using the jars >> provided by the geronimo tomcat assembly. The deployed app would be >> tracked only by tomcat, and not by geronimo. We should be able to >> achieve this without adding any new jars. >> >> If we need more than that, I can for seen the following issues that >> need investigation - >> 1. We'll have to provide better server integration with tomcat and be >> able to read the server configuration from tomcat's server >> configuration files, along with using config.xml configurations. >> > This would be an absolute minimal requirement. Would this be really > difficult? > >> 2. We'll have to migrate user's app automatically for the user, when >> the user's app is a bit complicated that contains any need to require >> a geronimo-web.xml >> >> > This is where things get more interesting.... lots of permutations > and edge cases to consider. I'm not enough of a tomcat expert to know exactly what information a server.xml contains so I'm not quite sure how much the following makes sense. I think I would approach this by building a namespace aware builder that can interpret documents following the server.xml schema and construct the entire tomcat server from it. In other words, instead of starting with our current tomcat6 plugin, the builder would construct a replacement for it from the server.xml. If server.xml contains info on apps that are deployed in the tomcat instance, this could perhaps hook into or extend the current TomcatModuleBuilder to also set up plugins for each web app involved. The first part here might not be too hard. IMO if we treat the server.xml as a geronimo plan that would be acceptable. I'd recommend trying jaxb rather than using xmlbeans. I don't know how practical this would turn out to be but it's worth starting with. I personally think this is too large an addition to plan to get into 2.2. However if a motivated person shows up with something working before we solve the other problems I think we could consider it. 2.2 is already so much later than we had planned I don't want to hold it up for any new features after the other problems have been solved. thanks david jencks > >> Lin >> >> On Mon, May 18, 2009 at 3:49 PM, Bill Stoddard >> wrote: >> >>> I know G can't consume tomcat configs today, but is this a feature >>> that >>> could be developed for G 2.2? >>> >>> Say I have an application successfully deployed and running under >>> Tomcat.. >>> wouldn't it be nice if I were able to drop the tomcat server >>> config into a >>> Geronimo-Tomcat assembly, start the server, deploy the app and be >>> up and >>> running in seconds. I'm talking about a seamless, zero effort/ >>> zero touch >>> migration from Tomcat to a Geronimo-Tomcat assembly. Is it >>> possible? If >>> not, what simplifying assumptions could be made to 'mostly' >>> achieve a >>> zero-touch migration? >>> What are the primary challenges with consuming a tomcat config >>> unchanged >>> with a G-Tomcat assembly? Same Q's apply for Jetty... what's >>> 'doable' >>> with-in reason? >>> >>> Thanks, >>> Bill >>> >>> >> >> >