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] Take III
Date Fri, 30 Aug 2002 16:05:35 GMT
In no particular order...

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

+1 for 1.0-M1, that would be helpful.


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

I understand, but then I loose type-safe polymorphism.  I can pass
Resource to methods expecting ResourceName, and (more importantly)
pass ResourceIterator to ResourceNameIterator.

>Why not moving the only method from ResourceClass into Resource?
Type-safety. When I get a ResourceClass, I *know* I can load it.
I don't have to check..  I'm removing complexity *from* the users
code.  Seriously, as soon as I broke things up, the errors in my
test code just jumped out at me.  I fixed the broken types, and
my tests ran fine.  No more guess work.


>Or even better - return Resource[].

If I knew how to defer file I/O, ClassLoader.getResource(), etc.
then I would much prefer this also.


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

The problem is performance again, particularly when working with
lots of little 'building blocks' that can be put together..
I want an holder of information that needs to be used in different
contexts.  Otherwise performance is a killer.

Yea, I know that in a majority of use cases discovery can be
contained as start-up cost.  However, we have had some discussions
where it appears that we could use discovery in a more central
manner for some scenarios.  Performance is becoming a concern.

One solution is to introduce an additional set of
API's (duck richard!): findFirst().
Also, for those cases where nothing is gained by defering - it
would be much better to use []'s... so a mix-and-match approach
might get me the best performance.


>The fact that we need a Log abstraction is a big 
>danger sign. We may become too complex.
Discovery is destined to be used in an Enterprise environment
which imposes certain restrictions on me.  I *need* to know
what's going on inside of discovery, and I *cannot* use System.out..
so.. Log.

Before you jump all over that, note that I've got a fairly
creative (yea.. and complex too) bootstrapping mechanism:

- I've copied ONLY the (current) Log interface & LogFactory
  in Discovery so that we don't have a build dependency on
  commons-logging.
- Discovery provides & uses it's own implementation of Log,
  so again it isn't dependent upon commons-logging impl.
  Likewise, I only invoke the LogFactory *if* it is given to me.
- Once a LogFactory is given to discovery, it goes back and
  resets all internal users of Log to use a Log implementation
  produced by the factory
- So, discovery can startup & log (to System.out) if nothing else
  is done.  On the other hand, a LogFactory can be given to
  discovery early on...

BE AWARE - due to the enterprise requirements, I'm probably going
to have to NLS-enable (i18n) this in the near future for both log
and exception messages.


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

Why?  It is my understanding that you CANNOT load the other
classes.  There is nothing the user can do, is there?  Hmm...
unless you write your own classloader... but then you can use
o.a.c.d.r.DiscoverResources(pathName + ".class") instead.

I suppose I could introduce another Discoverer for such a case,
but I think the general use will be to get the *one* class that
the ClassLoader would return.


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


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

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.

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