Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 88154 invoked from network); 18 Jul 2002 00:43:11 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 18 Jul 2002 00:43:11 -0000 Received: (qmail 25697 invoked by uid 97); 18 Jul 2002 00:43:33 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 25659 invoked by uid 97); 18 Jul 2002 00:43:32 -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 25647 invoked by uid 98); 18 Jul 2002 00:43:32 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Content-Type: text/plain; charset="iso-8859-1" From: Peter Donald To: "Avalon-Phoenix Developers List" Subject: Re: Management Metainfo Date: Thu, 18 Jul 2002 10:46:25 +1000 X-Mailer: KMail [version 1.4] References: <81BCB6FDA8961C4A82D175DEDBF45EF90278C288@mercury.mmlive.com> In-Reply-To: <81BCB6FDA8961C4A82D175DEDBF45EF90278C288@mercury.mmlive.com> X-Wisdom: A right is not what someone gives you; it's what no one can take from you. MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200207181046.25658.peter@apache.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wed, 17 Jul 2002 14:06, Huw Roberts wrote: > We need to select the format for how the metainfo will be stored > internally. I can think of three options > 1) new classes written for this purpose > 2) the java.beans classes plus a limited number of new classes > 3) the model mbean classes plus a limited number of new classes > > i thought about it a lot, and believe that using the model mbean classe= s > makes the most sense.=20 sounds good to me. there would also be a limited number of custom > classes to represent the additional structure that managed classes inhe= rit > from being written for/deployed to phoenix. the only draw back i can s= ee > is that as the jmx spec evolves phoenix management would need to stay m= ore > or less in step. i think its worth the tradeoff. does anyone have any > thoughts/preferences? I like JMX and think thats probably the best way to move. I would prefer = it if=20 no actual JMX code needed to be in the .sar file (I don't believe it does= ?)=20 and it was all done in the manager. (The manager can load xml descriptors= via=20 classes like object.getClass().getResourceAsStream("blah.xmbean"); > assuming that's good, i did a search on google for jmx and xml and one = of > the first things i came across was the common's own modeler package. i= t > includes utility classes for contructing model mbeans, and includes the > code to generate them from xml. would it be expedient to adapt that to= our > purposes? if so, would it get copied to excalibur? i don't know phoen= ix > stands wrt to the commons as they seem to overlap in some areas. I haven't actually looked at the commons one. I vaguely recall that it=20 registered a bunch of different mbeans per descriptor rather than just on= e.=20 Thus it is probably not suitable for us as such. Though it would be usefu= l to=20 use the same or similar format to describe the mbeans. --=20 Cheers, Peter Donald The big mistake that men make is that when they turn thirteen or fourteen= and all of a sudden they've reached puberty, they believe that they like wome= n. Actually, you're just horny. It doesn't mean you like women any more at twenty-one than you did at ten. --Jules Feiffer (cartoonis= t)=20 -- To unsubscribe, e-mail: For additional commands, e-mail: