commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: [discovery II] Ready for next review
Date Tue, 27 Aug 2002 20:30:01 GMT

A brief rundown of current history... after moving from sandbox to commons 
proper, we decided to refactor the entire scheme... the documentation 
refers to elements that were moved to  Hefter low-level 
elements are being introduced to o.a.c.discovery, and undergoing (almost) 
daily refactoring as we work out the design...

there are times when I wish we could just sit down at a table and plow 
through some of this, but the time lag gives everyone time to consider 

I'd appreciate your comments.  You are, of course, welcome to play with 
this, but I wouldn't check it into another project until after the current 
situation stabilizes somewhat...  I, like costin, think we are getting 

Documentation will be updated after we work a few more things out.


Richard A. Sitze
IBM WebSphere WebServices Development wrote:
> On Tue, 27 Aug 2002, Nicola Ken Barozzi wrote:
>>>>There is a grey area, in that 'class names' are not strictly 'resource
>>>>names' (though that point could be debated for quite a while).
>>>IMO classes are resources, class names are resources as well. 
>>IMV, I just want a
>>   Discoverer discoverer = Discovery.getDiscoverer(MyClass.class);
>>   List myObjList = discoverer.find(String hint);
>>   MyClass MyObj = (MyClass) myObjList.get(0);
>>and when I get the items from the List I cast them to what I
>>*know* comes out of the discovery operation, since I asked for the
>>discoverer that searches for that type (classResult).
> Well.. First, discover is not about 'hints', but well-defined 
> search order and algorithm. It has to support JDK1.1 ( for ant, jaxp, 
> common-logging ) - so no List. 

Ok, Vector will do ;-)
(List was just 4 the concept)

> It was also discussed that while 
> discovering a class is a  very important use case, finding general 
> resources is also important. ( i.e. ant.tasks, modeler mbeans.xml files, 
etc ). 


   Discoverer discoverer=Discovery.getDiscoverer(java.lang.Class.class);
   Vector myObjVector=discoverer.find("o.a.c.morphos.MorpherFactory");
   Class MyObj = (Class ) myObjVector.get(0);

> Most likely you'll have to be more explicit on what sources and 
> order must be used - but a quick shortcut to the very common
> ( system property -> java.home/lib properties -> thread loader -> system 

> loader ) search path can be provided. ( I don't think passing 
> is a good idea - what we need is a leaf Loader, and MyClass may be in 
> system loader ).

Hmmm, ok, then a String.

> You're welcomed to join the discussion - we're getting close (at least
> me and Richard ) and more input and review would be great. 

I would like to use it for Morphos, so I'm trying to get a sense of it.

I feel a bit lost without the use-cases you have in mind.

I read from the docs (see where I got the class param):
Given a java.lang.Class parameter 'package.Class' that represents a 
fundamental service as either an interface, an abstract class (or even a 
regular class), find an implementation of that class:

* Look for system property named 'package.Class', the value of which is 
the name of an implementation.
* Look for a 'local' property named 'package.Class'...
* Attempt JDK 1.3+ style discovery
* Attempt to load a default implementation

I give the first info to tell Discovery what I want the result to be.
Then I ask for it via a hint (can be anything, a classname, a hint, 
whatever), that hase sense for the discoverer I got in the first step.

In this case my example makes sense IMHO.

Could you please give me some links to the ones already covered?
Thanks :-)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message