commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <>
Subject Re: [discovery] code/design review [was Re: The exegesis]
Date Tue, 13 Aug 2002 23:15:46 GMT
I've been away for what have probably been six of the busiest days 
I've ever seen on commons-dev.  I've recently begun using Discovery, 
and I am very enthusiastic about having a consistent way to plug 
together implementations and interfaces in my projects.

I think step 1 is very good and I think it will clear up the 
increasingly complex API in Discovery.  Before I had caught up with 
this discussion thread, I had gotten caught up in one of the many 
variants of the "find()" method in DiscoverSingleton, nee Discovery.

Discovery could probably get by with three or four main public API methods:

public Class findClass(...)

public Object newInstance(...)

public InputStream getResourceAsStream(...)
public URL getResource(...)

perhaps with some variations based on the parameters provided.

The first would just give you the implementation class and leave you 
free to do what you want about it; the second would serve the common 
use case where the implementation class is understood to have a 
no-arg constructor, and the third would get you any configuration 
resources that you might need governed by the same rules as the basic 
discovery process.

I don't think the burden of using those resources (to make a 
Properties or feed an XML  parser) are so great that it's even worth 
a lot of trouble building up 2a -- or rather, once you start down 
that path, so many other questions come up that they should probably 
be addressed head on, and in consideration of the variety of other 
projects that try to solve similar issues (Avalon, Fulcrum, commons 
services, commons configuration, probably lots of others that I don't 
know about).

Just a few thoughts...

>I'm willing to put the following on the sacrificial alter, and burn it -
>if you so desire:
>A.  singleton, caching, anything related to life-cycle management.
>B.  propogating/passing properties file on to instantiated classes.
>Would you be satisfied (you don't have to be any happier than I am :-) to
>have a 'helper' or 'tool' package for some of the items you consider out
>of scope?  I'd break things down as follows:
>1.  Discovery (main):
>1.a.  find class name, including looking within a properties file (as per
>1.b.  load class/resource (finding/using class loaders in the correct
>manner is really central to the use pattern, and is one of the pieces that
>is difficult for a 'newbie' (like me) to get right)
>1.c.  ManagedProperties  this addresses specific issues related to use of,
>rather alternatives to, system properties that I require (1a) to use.
>2.  Discovery Tools/Helpers
>2.a.  class instantiation - I give you an interface, you give me an object
>implementing same.

* Joe Germuska    { }
"It's pitiful, sometimes, if they've got it bad. Their eyes get 
glazed, they go white, their hands tremble.... As I watch them I 
often feel that a dope peddler is a gentleman compared with the man 
who sells records."
	--Sam Goody, 1956

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

View raw message