commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [discovery] Take III
Date Fri, 30 Aug 2002 04:32:51 GMT
On Thu, 29 Aug 2002, Richard Sitze wrote:

> OK...  I've broken everything out into separate pieces.  Performance
> is about 1/3 where I started (3 times slower) two weeks ago  :-(

Well, I wouldn't worry about performance at this stage - this is not
in the critical path and it can be optimized. 

> Costin - you are gonna hate this:  I merged all *Info classes
> into ResourceInfo... It was a real nightmare to debug code.

I couldn't find ResourceInfo. I assume it's now called Resource.

> So, in the end I broke everything back out into three and
> renamed the whole bunch:
> - ResourceClass
>      extends Resource
>           extends ResourceName

I really hate:
1. ResourceName - just use String. All the JMX/JNDI that I know is 
fighting against this :-) An object has a name, but it isn't a name.

2. Iterator. Well, we need Enumeration for JDK1.1, but if this is 
too painfull we can use Iterator and collections. But another kind 
of Iterator - not sure.

Why not moving the only method from ResourceClass into Resource ? 
After all any Resource could be used as a class name. I really
like very simple things - at least for 1.0 ( that's probably just
a reaction to all the bloat in 2.x versions ... ). 

Resource + ResourceDiscover would make a really good pair :-) 

> [I really despised type-casting everything coming back
> out of Enumeration - error prone & confusing.  If
> someone really wants Enumeration, someone could probably
> write ANOTHER wrapper around *Iterator to give back an
> Enumeration]

If you really want ResourceIterator, why not making it a 
wrapper around Enumeration ? There are quite a few apis using 
Iterator or Enumeration. Or even better - return Resource[].

For the record - ClassLoaders also seems un-natural, and 
so is creating ResourceClassDiscovery and all other with ClassLoaders
in constructor... 
I think a regular java-beans pattern, with an emptry constructor
and then 'addClassLoader', etc would be much more intuititve.

I do like the DiscoverNameInXXX idea - well, I would have named
them FileDiscoverer, DictionaryDiscoverer, etc, but that's fine

The fact that we need a Log abstraction is a big 
danger sign. We may become too complex. 

> I mentioned this earlier, and you had some concerns - so one
> I'll go into more detail here:
>   DiscoverClasses is currently obtaining the URL of the class
>   by using loader.getResource() and stashing both the URL and
>   the loader in ResourceClass.  ResourceClass can later resolve
>   java.lang.Class using loader.loadClass().  While I don't see
>   an immediate need for the URL, going through the process
>   let's me identify the class & loader to be used later
>   (defered processing) if/when the class is actually loaded.
>   What I *don't* do is use getResources() - that simply gives
>   me a lot of classes that I may or may not be able to *load*.
>   [these are classes, not general resources].
>   I keep a history of classes found (URL), and only return
>   the first for duplicate URL's.  So, it's *possible* that
>   you might get back multiple classes found by different
>   class loaders.. then you have the URL's if you desire.

I don't think this is such a big problem - as long as we return
all the info we find. 
It is perfectly possible that some of the 'discoveries' are 
false hits. It's up to the user to filter and decide which one
is good and what to do with it.

> I'm in tomorrow, then out for the next week.
> It all seems to work *SLOW*.

If it's clean, it can be easily optimized. 

I'll be in tomorrow, then leave for a 3-week vacation. Most
likely I'll play with discovery in ant, and see how it works.
Probably some real use will help us find what is really needed.

As you probably noticed, I strongly believe in 'simpler is better'.

If you really need a 1.0 release - you have my +1, but I would
like if possible to keep the APIs unfrozen at least until
more people get a chance to play with it. Let's just do a
1.0-M1, get more feedback, see if we can simplify it more.


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

View raw message