Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 43592 invoked by uid 500); 20 Aug 2003 11:08:15 -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 43396 invoked from network); 20 Aug 2003 11:08:10 -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; 20 Aug 2003 11:08:09 -0000 Received: from apple.air.bandlem.com ([10.0.1.20] helo=ioshq.com) by dsl-217-155-97-61.zen.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 19pQoi-0007nL-00 for ; Wed, 20 Aug 2003 12:07:52 +0100 Date: Wed, 20 Aug 2003 12:08:01 +0100 Subject: Re: [JSR77] plug strategy proposal. 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: Message-Id: <9085CEFC-D2FE-11D7-870E-0003934D3EA4@ioshq.com> X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tuesday, Aug 19, 2003, at 16:01 Europe/London, Dain Sundstrom wrote: > On Tuesday, August 19, 2003, at 12:51 AM, gianny DAMOUR wrote: > >> Dain Sundstrom: >>> Can you tell me what your goal is, >> My intent is to propose an implementation of JSR77, which could >> potentially be re-used. > > Reused by whom? ...by some other container using something other then > JMX. I really don't see a demand for this, and adding another layer > of complexity (for something we don't plan on using) at this stage > seems like a bad idea. If it becomes a priority later we can easily > add the abstraction in. Actually, the more dependencies you hard-wire into JMX now, the more difficult it's going to be to put that abstraction layer in. Having it in now is both sensible from a design perspective, and also allows common services to be implemented using abstract classes that implement the interface, as opposed to a bunch of methods that get called through reflection. >>> I really don't understand why we need this abstraction layer. >> I would like to remove from the type hierarchy of the kernel >> components the specificities of JSR77. > > Our deployment system is fundamentally based on 77, but our kernel > only understand JMX and specifically doesn't do any 77 stuff. 77 is > really handled by the components, if they don't implement it properly > the kernel doesn't care. Other components will care if they depend on > something that does not properly implement the life-cycle, but the > kernel doesn't care in the least bit. The kernel is the right place to handle the 77 management; whilst it doesn't get handled by the kernel at the moment, it probably should do in the future. Alex.