Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 1788 invoked from network); 13 Jul 2002 10:40:32 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 13 Jul 2002 10:40:32 -0000 Received: (qmail 15339 invoked by uid 97); 13 Jul 2002 10:40:44 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 15313 invoked by uid 97); 13 Jul 2002 10:40:44 -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 15301 invoked by uid 98); 13 Jul 2002 10:40:43 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Subject: Re: Patch to Create a 'Local' Management Context (= SystemManager) From: Leo Simons To: Avalon-Phoenix Developers List In-Reply-To: <5.1.0.14.2.20020713201648.01c43790@www.stocksoftware.com.au> References: <81BCB6FDA8961C4A82D175DEDBF45EF90278C254@mercury.mmlive.co m> <5.1.0.14.2.20020713201648.01c43790@www.stocksoftware.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 13 Jul 2002 12:40:29 +0200 Message-Id: <1026556830.10191.0.camel@lsd.bdv51> Mime-Version: 1.0 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N really neat guys; thx! It all seems to work fine here... - Leo On Sat, 2002-07-13 at 12:19, Peter Donald wrote: > I ended up cleaning up the JMX stuff a little so that there is a > AbstractJMXManager that the two jmx imeplementations (Default and MX4J) > extend. I also reworked the hierarchy slightly so that the top part > (phoenix) is not present. > > Can you download it and check it out to make sure I did everythying correctly? > > Anyways it looks much cleaner after applying path - yea! > > At 08:15 PM 7/13/2002 +1000, you wrote: > >Hi, > > > >Fantastic. Just applpied the patch. I made some modificaitons, namely I > >moved SubContext to being a top level class as I try to avoid inner > >classes if possible. Other than that it works like a charm - thanks! It is > >a much cleaner approach to separating out different layers of management. > > > >At 11:40 PM 7/12/2002 -0700, you wrote: > > > >>This patch implements the concept of a 'local' management context that > >>objects are registered with. I think its better than spreading the JMX > >>naming scheme in different parts of the code. The big change is the > >>addition of the getSubContext() method to SystemManager. The contexts > >>are organized into hierarchy like this: > >> > >>Phoenix > >> Component List > >> Component 1 > >> Component 2 > >> Application List > >> Application 1 > >> Block List > >> Block 1 > >> Block 2 > >> Application 2 > >> Block List > >> Block 1 > >> Block 2 > >> > >>JMX naming is then derived by 'walking' up to the top level context, > >>which is the 'real' SystemManager. > >> > >>I've tested it with NoOpSystemManager and MX4JSystemManager and haven't > >>encountered any problems. > >> > >>An itemized list of changes: > >> > >>org/apache/avalon/phoenix/interfaces/SystemManager.java > >>- Added method getSubContext( String parent, String type ) to create a > >>subcontext > >> > >>org/apache/avalon/phoenix/components/manager/MX4JSystemManager.java > >>- Modified naming code slightly to be compatible with new scheme > >> > >>org/apache/avalon/phoenix/components/manager/AbstractSystemManager.java > >>- Added inner class SubContext, which implements SystemManager and acts > >>as the local context > >> > >>org/apache/avalon/phoenix/components/kernel/DefaultKernel.java > >>- Changed so applications register with the 'application' list context > >> > >>org/apache/avalon/phoenix/components/kernel/DefaultApplicationContext.java > >>- Changed so blocks register with the application's block list context > >> > >>org/apache/avalon/phoenix/components/embeddor/DefaultEmbeddor.java > >>- Changed so components are registered with the component list context > >> > >>The diff was made with the cvs diff -u >> patch diff from the > >>jakarta-avalon-phoenix/src/java directory. I hope this is right - or is > >>it better to diff each class seperately? > >> > >>This is part of the Management Proposal idea i sent out last week. I > >>think these are the only interfaces changes that are required and all the > >>rest of the work would be isolated behind SystemManager interface. > >> > >>Please let me know what you think. > >> > >>- Huw > >> > >> > >>-- > >>To unsubscribe, > >>e-mail: > >>For additional commands, e-mail: > >> > > > >Cheers, > > > >Peter Donald > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >"Faced with the choice between changing one's mind, > >and proving that there is no need to do so - almost > >everyone gets busy on the proof." > > - John Kenneth Galbraith > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > >-- > >To unsubscribe, > >e-mail: > >For additional commands, e-mail: > > > > Cheers, > > Peter Donald > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "Faced with the choice between changing one's mind, > and proving that there is no need to do so - almost > everyone gets busy on the proof." > - John Kenneth Galbraith > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > -- To unsubscribe, e-mail: For additional commands, e-mail: