commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [discovery II] Ready for next review
Date Tue, 27 Aug 2002 14:47:16 GMT
Richard Sitze wrote:

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

What I find confusing is all the code that first creates ResourceInfo
and then copies each one in a new ClassInfo. And the common code
that will do the discovery - and should create the right class.

Maybe an alterntative is to just treat it as a data holder - the 
discovery result. The discovery operation is more about finding stuff
in the classpath, and less about intepreting the results ( IMO ). 

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

Not sure about the last argument - finding multiple resources does translate
very well into beeing able to load one ( the first or the best fit or the
first that works ). I don't know what problem you see in the LOAD operation.

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

That's very strange. Why do we want that ? Do you have any use cases for 
those things ?

My opinion:

1. ResourceDiscovery is searching the classpath and finds some resources.
The 'resource' is a file in a class loader - it may be read as text or 
as a class, and the class may be considered a 'service', but from discovery
perspective we have files in the classpath, with a loader and URL.

2. The caller may use the files as classes. The difference between 'service'
and 'class' is very small - IMO, it's more on how you use that class.

3. We can provide various helpers to use the 'resource' as a service/class - 
i.e. create a class, instantiate it, read it as properties, etc. I 
personally don't think this is our core function, but you need it.

But regardless of interpretation, I think we are getting closer :-)
> 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.

Well, the URL and loader are very important, when they can be found. 

The 'resource' can be used as a class or just a file, and the caller
can choose what to use and how.  

I think we have a mismatch in terms:

I call 'discovery' the process of finding something by looking in multiple
sources. So 'ServiceSource' ( META-INF/services ), properties files, 
system properties, loader.getResources() are all sources for the discovery

The result of discovery is a list with what was found.

The real meaning of each 'discovery' is only known by the user, we just 
provide some helpers (to create classes for example ).

> B.  Introduce a PropertyDiscovery (extends ResourceDiscovery), returning
> C.  A DefaultDiscovery (or ConstDiscovery) extends ResourceDiscovery,
> 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.


It is very similar with what I have in mind ( we are getting closer, just 
use different vocabulary :-).

I can see benefits in having a single hook 'interface' ( Discovery ) that
can be extended by user. I was thinking of 'DiscoverySource' as the base,
and the Discovery using it. 

One small request - if we go this route, it would be very nice to keep
the 'base' classes and interfaces in a directory, and all impl classes
in a separate one. I usually like to quickly find the important 

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

+1 on ServiceInfo not needed.
Not convinced about the first part - I think we must find resources, and 
then eventually we should interpret them as class names and construct the 
classes ( or just let the user do it if he knows better ).

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


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

View raw message