commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: [discovery] Vote II, are we ready for RC1?
Date Thu, 15 Aug 2002 23:35:08 GMT
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.
> > 
> > <ras>
> > 
> > *******************************************
> > Richard A. Sitze
> > IBM WebSphere WebServices Development
> > 
> > --
> > To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> > 
> > 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message