commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
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 
that.

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

Discover.resources()    - returns Enumeration of ResourceInfo
Discover.services()     - 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 
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>



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