From james.todd@eng.sun.com Wed Jul 21 03:16:55 1999 Return-Path: Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 18370 invoked from network); 21 Jul 1999 03:16:55 -0000 Received: from mercury.sun.com (192.9.25.1) by apache.org with SMTP; 21 Jul 1999 03:16:55 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA11094 for ; Tue, 20 Jul 1999 20:16:53 -0700 (PDT) Received: from taller.eng.sun.com (taller.Eng.Sun.COM [129.144.250.34]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id UAA20925 for ; Tue, 20 Jul 1999 20:16:53 -0700 (PDT) Received: from eng.sun.com by taller.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA24843; Tue, 20 Jul 1999 20:16:50 -0700 Message-ID: <37953C49.F8929BEA@eng.sun.com> Date: Tue, 20 Jul 1999 20:19:37 -0700 From: James Todd Organization: Sun Microsystems X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tomcat-dev@jakarta.apache.org Subject: Re: request for review: server/config discussion References: <3794DCB6.D7A9872E@eng.sun.com> <3794E650.D038BB6A@algroup.co.uk> <3794EE1F.A98D643B@eng.sun.com> <19990720183708.B31037@usite.net> <37953417.A2485A91@eng.sun.com> <19990720225327.A649@usite.net> <01a101bed325$aa0975f0$35a602d8@ny.agency.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom Clarke wrote: > > How about we get a really good JSP/Servlet engine for V1 and go for a fully > abstracted configuration architecture in V2? > > What does it really buy us, apart from a really cool design? (Don't get me > wrong a properly abstracted configuration mechanism would be great - but if > I can configure it at all that's good enough for me) > > The main issue with a basic config file strategy that I can see is that it > should be a requirement to have multiple engines in a cluster running of the > same configuration file. Weblogic does this with basic configuration files > (it has one server which provides config information to the rest I think). > > Tom > agreed. i believe tomcat will be a really good first step for a jsp/servlet engine ... although here is and will continue to be work in that space pending spec mods, etc. with tomcat, we've started to factor out the config stuff and i feel the discussion to date excluding my "pieInTheSky" tangent is quite viable ... within bounds. regarding clusters reading off of the same config file, and i intend to flesh this out a bit more in the "config service" section of the discussion doc that i've bounced about, i believe a "config service" entity (object, service, whatever) can manage propogating config data as sourced from a local file or one which was sourced via a url. the only real difference, from the reading and processing of the data, is the scheme (local or remote file) and how best to determine changes (file mod data vs ?someDateMimeHeader?). it may not even be necessary for the "config service" to manage a singular file but could aggregate such data. the external config data/objects as provided by the "config service" most likely really shouldn't be exposed to the io or xml parsing details. as i see it anyways. batting these ideas about here really does help ... i/we need to get these thougths captured ... not ratified but none the less captured - james