Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 65773 invoked by uid 500); 8 Aug 2003 12:54:09 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: geronimo-dev@incubator.apache.org Delivered-To: mailing list geronimo-dev@incubator.apache.org Received: (qmail 65755 invoked from network); 8 Aug 2003 12:54:09 -0000 Received: from dsl-217-155-97-60.zen.co.uk (HELO dsl-217-155-97-61.zen.co.uk) (217.155.97.60) by daedalus.apache.org with SMTP; 8 Aug 2003 12:54:09 -0000 Received: from apple.int.bandlem.com ([10.0.0.20] helo=ioshq.com) by dsl-217-155-97-61.zen.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 19l6kz-000695-00 for ; Fri, 08 Aug 2003 13:54:09 +0100 Date: Fri, 8 Aug 2003 13:54:50 +0100 Subject: Re: JMX as a kernel (was: Re: geronimo and avalon?) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Alex Blewitt To: geronimo-dev@incubator.apache.org Content-Transfer-Encoding: 7bit In-Reply-To: <3F339200.5020003@apache.org> Message-Id: <7F6D540A-C99F-11D7-B192-0003934D3EA4@ioshq.com> X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Friday, Aug 8, 2003, at 13:05 Europe/London, Leo Simons wrote: > Why JMX Is Not A Very Good Kernel > ------------------ I'd definitely concur with this. Put it better than I could have done, too :-) Note that just because JMX isn't a kernel, doesn't mean that some parts of it can't be configured with JMX on top. It just means that not everything has to be JMX. Building a tighter smaller kernel gives me a gut feeling that it will run faster, though I've yet to convert that into measurable figures :-) But reducing (unnecessary) layers is bound to speed it up... One fear I have of using JMX as a kernel is that all the intra-kernel messages would be sent using JMX. If JMX isn't used in the kernel, then they can be made more efficient/optimised; but JMX can be put as a layer on top of the features (e.g. EJBs) that need configuring/managing by JMX. Definitely vote +1 for not using JMX 'just because' Alex.