Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 7594 invoked from network); 13 Dec 2001 21:20:29 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 13 Dec 2001 21:20:29 -0000 Received: (qmail 6835 invoked by uid 97); 13 Dec 2001 21:18:23 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 6806 invoked by uid 97); 13 Dec 2001 21:18:23 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 6766 invoked from network); 13 Dec 2001 21:18:22 -0000 Message-Id: <200112132118.fBDLILO11866@mail016.syd.optusnet.com.au> Content-Type: text/plain; charset="utf-8" From: Peter Donald To: "Avalon Developers List" Subject: Re: New Profiler hooks Date: Fri, 14 Dec 2001 08:15:14 +1100 X-Mailer: KMail [version 1.3.2] References: <3C177711.7090107@apache.org> <200112132048.fBDKmEu19421@mail012.syd.optusnet.com.au> <3C1918B1.7010209@apache.org> In-Reply-To: <3C1918B1.7010209@apache.org> X-Wisdom-Cookie: . MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 Fri, 14 Dec 2001 08:08, Berin Loritsch wrote: > The problem arrizes with how do we determine what the parent ProfilePoint > is? Same way as Logger, ComponentManager, Context, etc does. > It does not make sense to have a Pool's max active ProfilePoint be the > parent of an ObjectFactory's number of created instances ProfilePoint. > They represent something completely unique. eh? Could you rephrase ? ;) > If this is going to scale, we *have* to make it happen at the Profilable > level. Remember, this is IoC, so a child Profilable is not going to have > access to the Parent's ProfilePoints at all. and a child Profilable should not directly create its top ProfilePoint, IOC and all > > and the name would be set via > > > > parent.getName() + myName > > > > however the method getName() would be protected, package or private > > access (depending on what we could get away with) and done in the case > > class. > > I don't like this, as it is Subversion of Control. A child should not have > a direct reference to it's parent. The name has to come from being > assigned, or we trust the Component to use proper "divination" to generate > a meaningful name. why can't it operate like all our other hierarchial aspects? -- Cheers, Pete ----------------------------------------------------------- If your life passes before your eyes when you die, does that include the part where your life passes before your eyes? ----------------------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: