Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 66036 invoked from network); 28 Jun 2002 17:46:53 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by 209.66.108.5 with SMTP; 28 Jun 2002 17:46:53 -0000 Received: (qmail 26781 invoked by uid 97); 28 Jun 2002 17:47:03 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 26731 invoked by uid 97); 28 Jun 2002 17:47:01 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 26693 invoked by uid 98); 28 Jun 2002 17:47:01 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Subject: Re: [discovery] Use of ClassLoader in ClassFinder To: Jakarta Commons Developers List X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: rsitze@us.ibm.com Date: Fri, 28 Jun 2002 12:46:40 -0500 X-MIMETrack: Serialize by Router on D04NM201/04/M/IBM(Build M13TT_06062002 Pre-release 2|June 06, 2002) at 06/28/2002 13:46:46 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=09BBE175DFF30CC88f9e8a93df938690918c09BBE175DFF30CC8" Content-Disposition: inline X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N --0__=09BBE175DFF30CC88f9e8a93df938690918c09BBE175DFF30CC8 Content-type: text/plain; charset=US-ASCII More thoughts. First, regarding order of loaders, I propose the following based on feedback: thread context loader caller's class loader SPI's class loader ServiceFinder's class loader System class loader the only diff from Costins sequence is the addition of the 'ServiceFinder's class loader. Now, to eliminate redundancy, I'm going to walk the parents of each classloader and if I see that one of the above is also an ancestor of another lower in the above list, then I'm going to remove the duplicate loader from the list. >> In some cases we may want to force the discovery of a certain >> implementation set by container, for example if tomcat runs the apps in >> a sandbox and wants to force a certain trusted logger, even if the app >> includes an implementation ( in this case the impl. in WEB-INF/lib >> may not have the permissions - it's safer to grand it to a trusted >> logger under control ). >> > I don't agree with this statement. I don't have a long background working with J2EE environments, Tomcat, etc... So there may be some history that backs that up.. in which case I welcome the education. I'm of the opinion that container should either support what is deployed, or error out. In this case, if the permissions are not granted then the deployer is responsible for resolving the conflict by either removing the offending piece of code, or granting the permissions. If, on the other hand, WE are introducing a conflict that is either contrary to standard function, or not resolvable, then help me understand that... >To meet this need, we might want to make the discovery order configurable, >but then we're going to have the fun chicken-and-egg problem of how the >discovery algorithm discovers its own configuration settings ... I'm strongly against configuration for this... simple simple simple It may be that my ideals will have to break down in the face of reality, but until then... >> Costin >> >> >Craig Richard -- To unsubscribe, e-mail: For additional commands, e-mail: --0__=09BBE175DFF30CC88f9e8a93df938690918c09BBE175DFF30CC8--