commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: [discovery] Take III
Date Fri, 30 Aug 2002 20:35:57 GMT
>On Fri, 30 Aug 2002, Richard Sitze wrote:
>> Properties files are Resources that are not ResourceNames
>But they may have names :-)
>> Operations are Resource are getClassLoader(), getResource() and 
>> getResouceAsStream()  [so, Resource is strongly tied to ClassLoader].
>Why ? Resource can very well point to a file-system based info. 
>What matters IMO is the content - i.e. the name of the driver 
>or the available parsers or the task names. The classloader 
>is just a helper - and is visible only for advanced users. 
>> The additional operation on ResourceClass is loadClass(), which 
>> invokes ClassLoader.loadClass() only if it doesn't already have the 
>> Class..  This operation doesn't make sense for the more general 
>IMO the Resource has some content - and that content is in most 
>cases the name of a class. 
>We already discussed that the resource doesn't have to be in the same
>package with its implementation - and I think I found more use-cases
>for that. The loader that found the resource ( in case of 'loader 
>is just to inform what the source of discovery was.
>We alrady agreed ( and you implemened ) properties and system properties
>based discovery sources. Those have no associated classpath.
>We have:
>All those sources are used by the Discoverer to return Resources. 

No.. these (by whatever name) return names (String, ResourceName, 
whatever).  That gets fed to DiscoverResources or DiscoverClasses..

>If you want you can get rid of getClassLoader in Resource, and just 
>return getDiscoverySource(). Then the user will check if it was a 
>ClassLoaderDS and call getClassLoader() on the source.
>Do you think this is a reasonable compromise ? 
>I mean:
>  Resource: contains name( i.e. discovered 'thing'), discoverySource 
>            helper methods to construct a class ( lazy )
>  Discoverer: an array of DiscoverySource to be searched, each returning 
>              one or many Resource
>             methods: Resource findFirst(), Resource[] findAll
>  DiscoverySource: SPI, each source may have additional properties.

I like that direction. 

>> *******************************************
>> Richard A. Sitze
>> IBM WebSphere WebServices Development
>> Richard,
>> Can you think of some cases where we may have a different kind of 
>> Resource ( other than a name or a class ) ? My feeling is that 
>> a discovered resource will fundamentally be a string extracted from
>> some META-INF directory or some file - with a very common use 
>> as a class name. I can't imagine any 'typical' use of Discovery 
>> for something else. 
>> My point is that it makes a lot of sense to just have a single
>> object, Resource. It can be later expanded, but discovery 1.0 would
>> be much easier to use.
>> Also, 2 interfaces/abstract classes - ResourceDiscover and a SPI to be 
>> implemented by all o.a.c.d.resource.names/classes. 
>> I can live with the current model - I'm just trying to see if 
>> we can get one step simpler.
>> Costin

Richard A. Sitze
IBM WebSphere WebServices Development

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

View raw message