Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 30097 invoked from network); 26 Jun 2002 19:16:48 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by 209.66.108.5 with SMTP; 26 Jun 2002 19:16:48 -0000 Received: (qmail 29600 invoked by uid 97); 26 Jun 2002 19:16:36 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 29411 invoked by uid 97); 26 Jun 2002 19:16:34 -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 29212 invoked by uid 98); 26 Jun 2002 19:16:33 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Subject: Re: [discovery] Use of ClassLoader in ClassFinder To: commons-dev X-Mailer: Lotus Notes Build V60_M13_04302002 Pre-release 2 April 30, 2002 Message-ID: From: rsitze@us.ibm.com Date: Wed, 26 Jun 2002 14:14:10 -0500 X-MIMETrack: Serialize by Router on D04NM201/04/M/IBM(Build M13TT_06062002 Pre-release 2|June 06, 2002) at 06/26/2002 15:16:19 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=09BBE177DFFA1A7C8f9e8a93df938690918c09BBE177DFFA1A7C" 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__=09BBE177DFFA1A7C8f9e8a93df938690918c09BBE177DFFA1A7C Content-type: text/plain; charset=US-ASCII Sorry... SPI == Service Provider Interface OR Service Programming Interface. It's not stricly a Java Interface; it can be an interface, abstract class, or class. Example: org.apache.commons.logging.LogFactory could be a service provider interface. Call ServiceFinder.find(org.apache.commons.logging.LogFactory, ....) to locate an implementation of that interface. So, as-per my earlier note, the ClassFinder uses the context class loader and the class loader used to load LogFactory. ******************************************* Richard A. Sitze rsitze@us.ibm.com CORBA Interoperability & WebServices IBM WebSphere Development costinm@covalent .net To: Jakarta Commons Developers List 06/26/2002 11:43 cc: AM Subject: Re: [discovery] Use of ClassLoader in ClassFinder Please respond to "Jakarta Commons Developers List" On Wed, 26 Jun 2002 rsitze@us.ibm.com wrote: > One heads up... The loader attempts to find a service using the context > class loader, and failing that it tries the SPI Class's class loader. This > is NOT equivalent to Class.getName(), which would pick up the ClassFinder's > class loader. > > I believe this may be more appropriate.. but then again the SPI's Class > Loader is more likely to be equivalent to the context class loader... > thoughts? What is SPI ? Sorry, too many acronyms. It is likely that commons-discovery will be in the parent class loader, while the discovered packages in child loaders. Probably the 'right' thing to do is also try the class loader of the caller ( it is possible to get access to the call stack - with some hacks - like we do in c-logging). Costin ******************************************* Richard A. Sitze rsitze@us.ibm.com CORBA Interoperability & WebServices IBM WebSphere Development --0__=09BBE177DFFA1A7C8f9e8a93df938690918c09BBE177DFFA1A7C--