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 13:25:09 GMT
First, the most significant differentiation between ClassInfo and 
ResourceInfo is purely in the type system.  I find strong typing useful, 
even when the types have no functional difference (in this case they are). 
 I don't find it confusing.  I do find the converse confusing: one 
meta-polymorphic type makes the code MUCH more difficult to understand and 
use properly.

With that intro, my mind is going in circles again....  but each time 
around I think it's getting closer.


1.  ServiceDiscovery performs a three-step process: find resource names, 
find class names (read resource files), find classes.  It returns a set of 
classes, NOT a set of services (more on that in a moment).

2. ResourceDiscovery performs a one-step process: find a set of resource 
names.  While it CAN find a set of .class names, it's not appropriate for 
that use because finding multiple class names doesn't translate to being 
able to LOAD one.

3.  ClassDiscovery performs a one-step process: find the ONE URL per class 
loader that corresponds to a given .class.

So, I'm thinking:

A.  Break ServiceDiscovery BACK into a two-step process (much like your 
original): find resource names (using ResourceDiscovery), find class names 
(read resource files).  Returns a list of class names (URL & loader are 
meaningless, should return null?)  I COULD break this down into two 
separate steps, and build-up... but that may be taking things to far at 
this point.

B.  Introduce a PropertyDiscovery (extends ResourceDiscovery), returning 
ResourceInfo (URL & loaders are meaningless... starting to think needs a 
ClassNameInfo).  Returns (a list?) of class names (URL & loader are 

C.  A DefaultDiscovery (or ConstDiscovery) extends ResourceDiscovery, 
provides a 'default' name.  Returns a ResourceInfo[1]  (?[n]?).

D.  DiscoveryList/Discoverer/ChainDiscovery (extends ResourceDiscovery), 
much like ClassLoaders, lets me build up a list of ResourceDiscovery 
instances { PropertyDiscovery, ServiceDiscovery, DefaultDiscovery }.

E.  ClassDiscovery would be able to take a single classname parameter (as 
today) OR a set of classnames via String[], Enumeration (of ResourceInfo), 
or ResourceDiscovery (a parent of DiscoveryList) parameters.

This provides near-equivalent function to the original DiscoverClass (now 
in tools), and I believe it is extendable by users to provide their own 
rules.  There is another chain of events hiding in there... hmm.

Note that there are TWO types of tasks being performed:  1) Find names, 
and 2) Find classes.  Tasks performing (1) should return ResourceInfo, and 
Tasks performing (2) should return ClassInfo.  A 'ServiceInfo' type is not 

There is a grey area, in that 'class names' are not strictly 'resource 
names' (though that point could be debated for quite a while).


Richard A. Sitze
IBM WebSphere WebServices Development

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

View raw message