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 Mon, 26 Aug 2002 16:27:45 GMT
Do you have an opinion on the value of ClassDiscovery being a subclass of 
ResourceDiscovery?  This is the only reason why the names of the methods 
are 'findResouces' in ClassDiscovery and ServiceDiscovery.  I did it that 
way originally out of habit.  I don't see any real value for this, 
particularly since the return types are different...  yuch.  I'll fix 

Probably go ahead and move everything into one class, and call that 

Discover.resources()    - returns Enumeration of ResourceInfo     - returns Enumeration of ClassInfo
Discover.classes()      - returns Enumeration of ClassInfo

>A bit asymetric - don't we also need ServiceInfo ? 

What would it represent that isn't already available from ClassInfo?

Richard A. Sitze
IBM WebSphere WebServices Development

On Fri, 23 Aug 2002, Richard Sitze wrote:

> OK Costin, you win :-)

That doesn't happen very often, I should celebrate :-) 

> 1.  ClassInfo extends ResourceInfo.

You can add the getInstance() helpers in ClassInfo, if 
you want. 

Just looking at the code: toClassInfo() seems a bit strange, it should
be static or something like that. 

Maybe to avoid confusions and conversion we can just merge ClassInfo into 
ResourceInfo - or turn ClassInfo into ClassTools that processes 

BTW, also to keep it simpler: I would move 
ClassDiscovery.findResources() to ResourceDiscovery.findClasses()
Same for ServiceDiscovery -> findServices().

That's just cosmetics, it doesn't matter too much.

> 2.  All Discovery classes use Enumeration (it's ugly..)

We can return ResourceInfo[]. Easier for the user to manipulate,
and we can still preserve the 'lazy' evaluation.

I have no problem with Enumeration.

> 3.  ClassDiscovery & ServiceDiscovery return ClassInfo (not 
> through Enumeration.

A bit asymetric - don't we also need ServiceInfo ? 

> 4.  ServicesDiscovery has changes in semantics.  Yours returned 
> ResourceInfo with the URL & Loader of the META-INF/services/file.  I'm 
> convinced that what you really wanted was the URL and the loader of the 
> classes themselves, so it uses ClassDiscovery internally for each 
> 'service' found.

Well, if that's what I wanted :-) ...

You're right, the Loader and URL for the class itself is what matters -
I (wrongly) assumed that the descriptor will be in the same .jar with
the classes. This is not allways the case.

> 5.  Services ala Java/Jar document: something like that is in tools

I think I started to understand ManagedProperties. It's an interesting
idea, but I'm afraid to even think of tomcat's loader hierarchy ( and
the 'reversed' loader order, with child-first ). 

I still feel this is a bit to complex - but if you need it 
this way I won't complain.

> 6.  Original 'stuff' moved down into tools, and otherwise cleaned up. 
> internal extensions dropped.. you can use the simple tools, or not.



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

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

View raw message