Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 95552 invoked from network); 10 Jul 2002 10:46:18 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 10 Jul 2002 10:46:18 -0000 Received: (qmail 21288 invoked by uid 97); 10 Jul 2002 10:46:28 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 21269 invoked by uid 97); 10 Jul 2002 10:46:27 -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 21252 invoked by uid 98); 10 Jul 2002 10:46:27 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) From: "Carsten Ziegeler" To: "Avalon Developers List" Subject: RE: Optional Dependencies Date: Wed, 10 Jul 2002 12:48:54 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200207102036.53257.peter@apache.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 10.07.2002 12:46:06, Serialize by Router on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 10.07.2002 12:46:07, Serialize complete at 10.07.2002 12:46:07 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Peter Donald wrote: > > On Wed, 10 Jul 2002 20:30, Carsten Ziegeler wrote: > > > It is unfortunate that ECMs lookup is costly. Does Fortresss have > > > this problem > > > aswell? Most containers I work with are little more than a hashlookup. > > > > Even if the lookup is not costly, what about non ThreadSafe components? > > For example the XSLTProcessor is configured to not use the Store, > > the Store would be Poolable (as the XSLTProcessor is) and the > XSLTProcessor > > looksup a Store in compose(). > > So each XSLTProcessor component would block a Store component, although > > this would not be necessary. > > true. But XSLTProcessor would bugger up all those components now > as I removed > the release() ;) > > I looked at all the store implementations and they all were > threadsafe and I > applied the same logic as I did wrt the XMLizer/Parser. ie If all > implementations are threadsafe then dont worry about releasing > the component. > > If the component was poolable then what I did would not be good - > it would > suck actually ;) > Yupp :) Ok, I totally agree with you that if I know that the component is ThreadSafe, your solution is OK. But I repeat my message from some weeks ago: the client should not know anything about if the used component is thread safe or not. But that's (only?) my opinion. So, keeping it short: you won ;) Carsten -- To unsubscribe, e-mail: For additional commands, e-mail: