Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 39302 invoked from network); 6 Sep 2002 03:15:49 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 6 Sep 2002 03:15:49 -0000 Received: (qmail 25353 invoked by uid 97); 6 Sep 2002 03:16:30 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 25313 invoked by uid 97); 6 Sep 2002 03:16:29 -0000 Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon-Phoenix Developers List" Reply-To: "Avalon-Phoenix Developers List" Delivered-To: mailing list avalon-phoenix-dev@jakarta.apache.org Received: (qmail 25301 invoked by uid 98); 6 Sep 2002 03:16:29 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Thu, 05 Sep 2002 23:04:48 -0400 From: "David W." Subject: Re: More configurable SystemManager. To: Avalon-Phoenix Developers List Message-id: <001901c25552$552eb9c0$c600a8c0@dellinspiron> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <004401c25493$606b84e0$5eb2c4d3@nervous> <002a01c2552b$c5c87a80$c600a8c0@dellinspiron> <001501c2553a$c2dcf580$5eb2c4d3@nervous> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > > Separated configuration is so complicate. > Configuration is just for SystemManager's configuration. > I decided to think. Some of my thoughts are below if you care to read them. Phoenix could, in theory, configure everything using the format and JMX (at least if it required all Blocks to be MBeans). It would probably even be a more flexible solution, although more verbose. But currently it has it's own configuration format, and the two are in direct competition. In my opinion, keeping them separate would allow greater flexibility in the future -- although I'm not really in a position at the moment to judge the direction of the project ;). I'd be content, in the short term at least, to see more descriptive versions of the same thing (i.e. instead of number to configure the http adaptor, number) until JMX configuration is given full consideration. I'm not really very passionate about the issue, though -- just very bored tonight. David Weitzman Some thoughts, which may be self-contradictory and unrelated: Thought 1) Services like the HTTP and RMI are not directly dependant on SystemManager, nor vice versa. The need for them to be associated is that there is no other way to register MBeans at the moment. Thought 2) The things currently managed by SystemManager come with the Phoenix binaries, and aren't going to gain any new functionality between releases, so dynamic configuration isn't strictly-speaking necessary. A simple but expressive and complete custom configuration would be more concise and require less knowledge of the inner workings of the services being configured, but would require modification any time new ways to access JMX are added.. Thought 3) Since the format already exists and can be implemented without relying on any particular JMX vendor, directly using DOM would make an implementation reusable outside of Avalon (which may not matter). Thought 4) Phoenix does not currently provide a configuration method that allows the user to execute/make available arbitrary JMX-compliant beans. That is precisely the problem that the format is designed to solve. That format is actually directly competing with Phoenix's own methods of configuration, just without inherent support for features like the Avalon lifecycle (which could easily be made available). It is a separate and complete solution -- why make it dependant on Phoenix configuration files? -- To unsubscribe, e-mail: For additional commands, e-mail: