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 20:08:06 GMT
>But simpler is better: Discover -> DiscoverInfo
Distant memories of a late night are starting to emerge.  As it stands:

    ClassDiscovery extends ResourceDiscovery
    ClassInfo extends ResourceInfo

I can pass a ClassDiscovery object to a method that is looking for a 
ResourceDiscovery parameter.. and the method will be able to retrieve a 
valid ResourceInfo (alias ClassInfo) [assuming if finds anything].

ServiceDiscovery is broken: it ought to extend ClassDiscovery, NOT 
ResourceDiscovery.  For the sake of symetry and possible future growth, 
I'll change/add:

    ServiceDiscovery extends ClassDiscovery
    ServiceInfo extends ClassInfo

Finally, if I merge everything, we have no way to grow/extend without 
adding addtional method(s).

I'm going to make the above changes, and drop the idea of merging for now.

>I was thinking about the 'policy' stuff - and I was thinking of
>an alternative ( and simpler ?) solutions:

Funny you should say that... remember my indiscriminate use of a 9-letter 
'F' word?  I was heading this direction without the foundation we now 
have...  I had some problems with how to do it, but I think a ResourceInfo 
hierarchy will alleviate those (PropertyInfo w/ PropertyDiscovery & a 
ChainedDiscovery or somesuch.. hmm).

I'll see what I can do moving forward, but it's likely to be slow with 
short bursts.

<ras>

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development


On Mon, 26 Aug 2002, Richard Sitze wrote:

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

If we merge ClassDiscovery, ResourceDiscovery, ServiceDiscovery - then
probably it make sense to also merge ResourceInfo, ServiceInfo,
ClassInfo. Some fields will be null where they don't make sense.

My comment was only 'cosmetic' - no extra info, just symetric naming.
( i.e. if ClassDiscovery returns ClassInfo, RD -> ResourceInfo, then
ServiceDiscovery should return ServiceInfo ).

But simpler is better: Discover -> DiscoverInfo

I was thinking about the 'policy' stuff - and I was thinking of
an alternative ( and simpler ?) solutions:

We could implement the 'policy' order by just adding multiple
sources to the Discover. Right now we can add loaders as the 
source of discovery, but you can add a 'addPropertySource', etc.  The
behavior - each source will be searched. If a property source is added,
we'll look for the file and read it if present, etc. The result will be
an [] ( or Vector ), with ordering given by the order of sources.

For example: 
  Discover jaxpDisc=new Discover();
  jaxpDisc.addSystemPropertySource( "javax.xml.parsers...." );
  jaxpDisc.addPropertiesSource(javaHome +"lib/jaxp.properties" );
  jaxpDisc.addLoaderSource( Discovery.getThreadClassLoader() );
  jaxpDisc.addLoaderSource( this.class.getClassLoader() );

  DiscoverInfo jaxpInfo[]=jaxpDisc.discoverServices();
 
  ParserFactory=jaxpInfo[0].createClass();

  ( alternative: create the factory for each discoverInfo and check if
   it suports schema - or something like that. )
 

Costin 



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


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