Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 46472 invoked from network); 16 Aug 2002 17:43:20 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 16 Aug 2002 17:43:20 -0000 Received: (qmail 27608 invoked by uid 97); 16 Aug 2002 17:43:46 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 27571 invoked by uid 97); 16 Aug 2002 17:43:45 -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 27556 invoked by uid 98); 16 Aug 2002 17:43:45 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Fri, 16 Aug 2002 10:39:37 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Jakarta Commons Developers List Subject: Re: [discovery] Vote II, are we ready for RC1? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Thu, 15 Aug 2002 rsitze@us.ibm.com wrote: > RE: your first request below, seems to me that once I've got loader/URL, > I've already got the Class (unless you've got an 'in' with the > classloaders that I'm not aware of). And I'm NOT sure how you get the > URL! Not sure I answered this clearly enough: You may have the loader and the class name, but that doesn't mean you have the Class. The loader may be modified by addURL to add class dependencies - and only then you'll be able to load the class. Lazy creation is very important in cases like ant, where even the actual class definition may be available only later. For URL - getResources() is the answer. Costin > > RE: merging constructors/methods: which classes are you talking about? > > > > ******************************************* > Richard A. Sitze > IBM WebSphere WebServices Development > > > Actually... I'm wrong about String[]. > > I think the 'generic' return type should be DiscoveryResult[], with: > > class DiscoveryResult { > String name; // name of > ClassLoader loader; // loader used to find the .jar > URL location; // path the the jar containing the entry > } > > What would you think about merging the methods/constructors and > having only the most generic one ( and 'null' used for unknown > values ) ? It would make things easier to read IMO. > > The DiscoveryResult can also simplify the life if you want to > create the class or instance later. > > Costin > > > On Thu, 15 Aug 2002 costinm@covalent.net wrote: > > > > > A quick comment - still need to review the rest: > > > > What happens if you have multiple implementations ? Either the manifest > is > > found in 2 jars, or one file contains multiple lines ? > > > > For jaxp and logging - the use case is obviously a single driver, in > > the specified order. But the spec allows for multiple drivers to > > be found. > > > > Use case: ant using discovery to locate tasks ( assuming the name > > associated with a task can be determined from task or some conventions). > > Each jar can contain one or more ant tasks - you want to return > > an array. > > > > Also in this use case: some of the tasks may depend on jars that > > may be added dynamically, later. For example junit task depens > > on junit.jar, which is not available at the time junit task > > is discovered. The model in ant is to instantiate ( and do > Class.forName) > > very late - before execution. Discovery doing Class.forName prevents > > that. So we need a method returning String[]. > > > > And finally ( same use case ): ant supports the notion of 'adapters' - > > the class may not extend Task ( the abstract class we look for ) - but > > still be valid tasks using the task adapter. That would work with > > the current API, but the wording ( the result implements ... ) doesn't > > fit. > > > > > > > > Costin > > > > > > > > > > On Thu, 15 Aug 2002 rsitze@us.ibm.com wrote: > > > > > I'm once again ready to push out an RC1. I could ask for comments, > but > > > that doesn't seem to generate as much interest as calling for a vote! > So, > > > here is my > > > > > > +1 for releasing commons-discovery RC1 > > > > > > **** > > > > > > I believe I've resolved the serious issues. A few highlights of > > > significant changes: > > > > > > - removed life-cycle support. We can add features to help support > later, > > > if someone so desires (via events). > > > > > > - a reasonable (probably still too many) set of 'find' and > 'newInstance' > > > methods. [If you want more control, use Environment, SPInterface, and > > > > ImplClass directly] > > > > > > - moved 'don't-depend-on-me' code OUT of discovery & discovery.base > > > packages, into discovery.tooling package. > > > > > > - removed caching-by-groupContext. I still use the groupContext to > > > qualify various properties & property file names, but the more I think > > > > about it, the more I don't want it in the cache yet. It's easier to > add > > > than remove later... so it's gone. > > > > > > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: