commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: [discovery II] Ready for next review
Date Fri, 23 Aug 2002 23:01:50 GMT
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 
ResourceInfos. 

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 ResourceInfo) 
> 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. Most 
> internal extensions dropped.. you can use the simple tools, or not.

Great.

Costin


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