commons-dev mailing list archives

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

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 o.a.c.d.tools.  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 
ramifactions.

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

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

<ras>

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development



costinm@covalent.net 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 ). 

Sure:

   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 
MyClass.class
> is a good idea - what we need is a leaf Loader, and MyClass may be in 
the 
> 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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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