commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rsi...@us.ibm.com
Subject Re: [discovery] Vote II, are we ready for RC1?
Date Fri, 16 Aug 2002 00:12:09 GMT
During your review, take a look at 
discovery.strategy.DiscoverStrategy.discoverClassNames().  You can use 
that directly...  Seems like a starting point to build up your next step.

I see your point with ant... We have divergent (but not contradictory) 
directions.  At one end, I'd prefer NOT to find all strings (but I coded 
it because you mentioned it in an earlier note), JUST the first one.  If 
the first is not available, then (the theory) was throw an exception, 
something is configured incorrectly (and you are about to give me a 
use-case to contradict that, aren't you :-).  Even IF we keep going and IF 
we are going to load the class internally, I would want to cycle through 
'find-string, load-class, find-next, load-next' etc  to minimize 
performance impact (classloaders can have a significant runtime cost :-( 
).

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!

RE: merging constructors/methods: which classes are you talking about?

<ras>

*******************************************
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.
> > 
> > <ras>


--
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