Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 66207 invoked from network); 1 Aug 2002 17:17:26 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 1 Aug 2002 17:17:26 -0000 Received: (qmail 28211 invoked by uid 97); 1 Aug 2002 17:17:46 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 28195 invoked by uid 97); 1 Aug 2002 17:17:46 -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 28183 invoked by uid 98); 1 Aug 2002 17:17:46 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Reply-To: From: "Berin Loritsch" To: "'Avalon Developers List'" Subject: RE: [RT] pooling vs. release Date: Thu, 1 Aug 2002 13:16:51 -0400 Message-ID: <002601c2397f$3a3a3c00$ac00a8c0@Gabriel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <200208011911.54996.tcurdt@dff.st> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > From: Torsten Curdt [mailto:tcurdt@dff.st] > > On Thursday 01 August 2002 19:07, Berin Loritsch wrote: > > > From: Berin Loritsch [mailto:bloritsch@apache.org] > > > > > > BTW, fillInStackTrace() is a native method (AKA a JNI method). > > > > oh yeah, it is synchronized as well. > > > > Creating tons of exceptions in a multithreaded environment is not > > advised. > > well, a boolean should do it (see example) and the Exception > could be created > in finalize. Is there any other way a component could be > aware of if it is > used or not? > -- > Torsten I think you are asking the wrong question. Should an entity that is managed and controlled by an external force have any say in how it is managed? The answer to that is no, it violates COP principles. Is this something that can be automagically added to any component by a dynamic proxy without any maintenance necessary in the hundreds of components we already have to maintain? Yes. Therefore, something like this should be an added feature of the container--making security and tracking this type of issue easier to maintain. One thing that is already doable in Fortress is adding request/release Instruments, and we can see if certain components are not being used in a balanced manner. -- To unsubscribe, e-mail: For additional commands, e-mail: