commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [discovery] code/design review [was Re: The exegesis]
Date Tue, 13 Aug 2002 00:05:53 GMT
On Mon, 12 Aug 2002 wrote:

> My intended purpose, however, was/is to allow you to go beyond that, if 
> you choose... therefore, IF you use the correct API then it looks in 
> properties files... IF you use the correct API it initializes, etc.  It 
> was never intended to be limited to JUST the JDK13 META-INF support.

I think that's out of scope for discovery, and even for commons.

You may consider moving this to sandbox ( for example in [paterns] :-),
or to a different component. I'm ( quite strongly) -1 on doing it
in discovery.

Craig - what's your opinion ?

> I don't suppose I have a single *spec* that I'm working with.

Then propose a different commons component for the other. 

> Discovery provides a few layers of 'service':
> 1.  Discover class (returns Class, not string - you indicate that you 
> don't even want this to load the found class?  I'd be happy to add another 
> layer - return 'list' of discovered class 'names' in order...)

Not sure - Class is probably ok ( I slightly prefer String and let the
caller do whatever it wants, it may not want to initalize it imediately - 
for example in ant it may make sense to delay it until it's actually 
needed ).

> 2.  Discover class, instantiate new instance.

Intantiate should be done by the caller, when it wants to and how 
it wants to.
> 3.  Discover class, manage as a 'singleton' within a context (thread 
> context class loader).

That's another thing that should be done by the project calling that 
in the way it wants. 

> 4.  Finally, loading resources is as much a part of the classloader as 
> loading clases, so discovery supports this.. [HOW we use it internally can 
> be debated further, but I hope you aren't asking that I remove that 
> also...]

Finding resources may be fine - but not processing them, i.e. a feature
to find properties file in different loaders or something named 
META-INF/ant.tasks or META-INF/antlib.xml would be nice. As long as you 
don't try to interpret it.

> It does these with varying degrees of sophistication - at the one extreme 
> your input is ONLY a (interface) class.  At the other extreme, you 
> indicate the interface class, property name, parameters for constructor, 
> property file name, default implementation (and it's constructor 
> parameters)....  These are bread out of requirements, and are NOT intended 
> to be used in the general case, but ARE intended to provide that level of 
> service to code that repeats such patterns...

I'm -1 on this. Let's make it complex if we really need to.

> >From what I can tell, you are asking me to do (1) and only (1).  I'm not 
> in agreement with that.

No, I'm asking to do (1) as commons-discovery and the rest as a 
separate component ( commons-config ? commons-lifecycle ? ). If you
get the votes for that.

> One driving force is to be able to replace a lot of code that in other 
> projects without changing the behavior (both commons-logging and axis). At 
> one level I'd like to preserve the "pure" interfaces more in line with 
> what you are talking about, but at another level support more complicated 
> discovery patterns.

You don't need to replace 'a lot of code' - just the code that deals with
discovery. And doing it in the most correct way is more important than 
having tons of features or covering other areas.

I doubt there will be much adoption for this if you try to also get
into lifecycle/config.


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

View raw message