You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Richard Sitze <rs...@us.ibm.com> on 2002/08/30 04:50:56 UTC
[discovery] Take III
OK... I've broken everything out into separate pieces. Performance
is about 1/3 where I started (3 times slower) two weeks ago :-(
The basic modules are in o.a.c.discovery.
Real function is in o.a.c.d.resource.*.
I'm not really happy about the resultant names.
Costin - you are gonna hate this: I merged all *Info classes
into ResourceInfo... It was a real nightmare to debug code.
So, in the end I broke everything back out into three and
renamed the whole bunch:
- ResourceClass
extends Resource
extends ResourceName
For better type-checking all around, there are also:
- ResourceClassDicover
extends ResourceDiscover
extends ResourceNameDiscover
- ResourceClassIterator
extends ResourceIterator
extends ResourceNameIterator
[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]
Debugging became a breeze... sorry to do that to you, but I
think it really is more usable.
So, now you can easily string a bunch of ResourceNameDiscover
implementation classes (found in o.a.c.d.resource.names) together
using 'o.a.c.d.resource.names.NameDiscoverers', then hand the
whole bundle to either 'o.a.c.d.resource.DiscoverResources'
or to 'o.a.c.d.resource.classes.DiscoverClasses'.
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'm in tomorrow, then out for the next week.
It all seems to work *SLOW*.
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ryan Lubke wrote:
> Out of curiosity, what tool was used to generate the UML diagrams?
http://sourceforge.net/projects/essmodel
> -rl
>
> On Fri, 2002-08-30 at 09:22, Richard Sitze wrote:
>
>>Very nice, thank you.
>>
>>I know keeping this up-to-date may become an interesting project, but at
>>some point it might be nice to drop that into CVS.
I'll write a centipede cent then, so that it can be part of the
documentation process.
>>UML diagrams to understand better:
>>
>>http://cvs.apache.org/~nicolaken/discoveryUML/overview.html
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by Ryan Lubke <Ry...@Sun.COM>.
Out of curiosity, what tool was used to generate the UML diagrams?
-rl
On Fri, 2002-08-30 at 09:22, Richard Sitze wrote:
> Very nice, thank you.
>
> I know keeping this up-to-date may become an interesting project, but at
> some point it might be nice to drop that into CVS.
>
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development
>
>
> UML diagrams to understand better:
>
> http://cvs.apache.org/~nicolaken/discoveryUML/overview.html
>
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> --
> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by Richard Sitze <rs...@us.ibm.com>.
Very nice, thank you.
I know keeping this up-to-date may become an interesting project, but at
some point it might be nice to drop that into CVS.
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
UML diagrams to understand better:
http://cvs.apache.org/~nicolaken/discoveryUML/overview.html
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by Nicola Ken Barozzi <ni...@apache.org>.
UML diagrams to understand better:
http://cvs.apache.org/~nicolaken/discoveryUML/overview.html
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by co...@covalent.net.
On Fri, 30 Aug 2002, Nicola Ken Barozzi wrote:
> > 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 see too many methods, which is usually a recipe for disaster.
> It makes it more difficult to debug and to use.
> If it's used by so many methods, having a bean-like method is really
> preferrable.
I agree, too many methods and too many classes that the user needs to
learn are usually a bad sign.
Ant has hundreds of classes, but only 5-6 that really matter as API.
> > The fact that we need a Log abstraction is a big
> > danger sign. We may become too complex.
>
> ?
Commons-logging will depend on discovery, and it's weird to have
discovery depend on c-l. But if we end up needing log, it may be
good to just build them togheter.
> > 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.
>
> Hmmm...
> I think this is too much work for the user.
> I want good results, if I still need to filer them I could as well do it
> all myself.
We do provide a helper for the typical jaxp/c-l use case ( where you want
a single driver, filtered/selected by discovery ). Think about ant or
JDBC - discovery will tell you what tasks ( or drivers ) are available,
but some may not work ( lack of dependencies ).
> Let's try it in other projects like Morphos (which needs a JAXP-type
> discovery) and see how it works.
>
> I still have problems going over the code though, the package hierarchy
> seems so confusing :-S
Then make proposals on how to simplify it. That's what I'm trying to
do - this is commons and everyone can participate. Feedback and
peer review and contributions is what makes open source work.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by Nicola Ken Barozzi <ni...@apache.org>.
costinm@covalent.net wrote:
> 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.
+1
>>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.
+1
> 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 :-)
:-D
>>[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[].
Not bad at all...
> 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 see too many methods, which is usually a recipe for disaster.
It makes it more difficult to debug and to use.
If it's used by so many methods, having a bean-like method is really
preferrable.
> 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.
Hmmm...
I think this is too much work for the user.
I want good results, if I still need to filer them I could as well do it
all myself.
>>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.
+1
Let's try it in other projects like Morphos (which needs a JAXP-type
discovery) and see how it works.
I still have problems going over the code though, the package hierarchy
seems so confusing :-S
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Richard Sitze wrote:
...
> Costin write:
>>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...
I've done a similar thing for POI.
The fact is that users start jumping all over the place like mad because
they are not able to configure commons logging or any other logging
system that they have in their app.
They really blew the hell out of me!
So, here is what I've basically done (maybe we can make this a very
simple _grab_your_facade_template project ;-)
http://jakarta.apache.org/poi/utils/logging.html
> 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.
This should become part of commons logging or the like, since it's a
fairly common concern.
>>>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.
Yes, this is more KISS for the user +1
Unless Costin has a real need for it ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by co...@covalent.net.
On Fri, 30 Aug 2002, Richard Sitze wrote:
> >Same info can be used either way. The user is required anyway to
> >know what he is looking for - and the name and where it should look
> >and in what order. It is not absurt do expect him to know if he's
> >looking for a class that he wants to instantiate or just a class.
>
> But is my (generic) method getting a (file) resource or a class?
> The parameter type communicates to me & my users what I'm expecting: a
> class.
Discovery will return a Resource object. Your code can call
resource.getClass() it it expects a class. If
Resource r=discovery.findFirst()
Class c=r.getClass()
is too complex, we can add a findFirstClass() wrapper.
If you know the discovered resource referes to a class, the
call is perfectly equivalent with 'ResourceClass rc=....'.
Even if you expect a class name - and eventually a class, there
are valid use cases where you could just use the name ( for
example - display a list of drivers, or do lazy construction
of the class ).
The way the result will be used ( as a Class or just the class name,
displayed in a selection box ) is selected by user, but doesn't
determine a clear 'IS_A' from discovery perspective.
> >And I don't agree you 'know' you can load it. You may know that
> >the class is defined in META-INF/services, and you may even know
> >that the class is in the classpath - but you may not be able to
> >load it or instantiate it ( for example because of missing
> >dependencies ).
>
> If it's a ResourceClass from a ResourceClassIterator, it's loadable by the
> ClassLoader. I *know* I can load it (barring security exceptions.. I/O
> problems, etc).
You know that the driver is available and the name. You don't know
if it can actually be loaded or when.
Simple example: you can discover a list of JDBC drivers. Some may use
JNI and you may be unable to load them. Another example: you discover
the 'junit' task. You can't load it imediately, but you the script
may add junit.jar to the ant loader and you may load junit task later,
just before use ( but not at the time of discovery ).
> Ahh.. perhaps a bit of mind-sync will help here. With current scheme we
> have DiscoverServiceNames... no longer do I have a DiscoverService
> (though it would be easy to add). DiscoverServiceNames returns (for now)
> ResourceNameIterator, not ResourceIterator. **There is not a guarantee
> that a class of a given name exists or can be loaded until is goes through
> DiscoverClasses** DiscoverClasses has a
> findResourceClasses(ResourceNameIterator) which will resolve a 'list of
> names into valid classes.
Richard - the creation of the class _must_ be lazy, at least in the
generic method.
It is ok to have specialized methods that return the first found or
only the classes that can be loaded, but this is not the general case.
A Service is a Class, I think we agreed we don't need an explicit
distinction - it's just a different convention on locating it
( i.e. META-INF/services/class.name ). There are many 'sources',
one is the service spec, the other is properties, other may be
a contention like META-INF/ant.tasks. Yet another one may be the
MANIFEST or the jndi driver convention.
> >Resource can do the deferal. ( i.e Resource.getXXX would do the
> >operation, instead of putting it in the constructor ).
>
> That would work for some cases, but not all. Maybe my answer is to go
> ahead and use [] in the general case, but provide a ResourceIterator for
> those that don't. Now that I have all the logic mapped out, I'll go back
> through & see exactly which ones still benefit from an Iterator...
Can you give me an example when it won't work ?
Note that my objection was mainly on creating our own Iterator -
if you want typed result you can use Resource[], if not you
can use Enumeration, java.util.Iterator or Vector or List.
> >Then use the bean model and reuse the bean.
>
> Can't. I've got multiple discoverers strung together:
> - DiscoverNamesInSystemProperties
> - DiscoverNamesInDictionary
> - DiscoverServiceNames [extends DiscoverNamesInFile,
> which requires a set of class loaders]
> All of which get sent through DiscoverClasses [requires class loaders]
I see.
Ok, then:
Discoverer.addClassLoader(), -> add as many loaders as you want, they'll
be used to resolve/verify classes in properties
Discoverer.addSource() -> add the sources in the desired order.
DiscoverNamesInClassPath -> a DiscoverSource that will look in the list
of loaders that were configured in Discoverer ( or in it's own separate
list ) with getResources().
The Discoverer is a regular bean that can be reused, you explicitely
add each class loader - and the loaders are used to load classes ( when
the user asks for a class or if you set a property requiring validation
of the found classes ). ( the 'validate class' flag can be used to
distinguisg between our use cases ).
DiscoverNameInClassPath can also be a regular bean, which can use
info in Discoverer ( the configured loaders ) or its own path.
> A model that requires that the list be built up in each case (and how many
> OTHER discovery sequences might I build up in a system?) just seems like
> unnecessary work (code to write) for user and for Discovery (code to
> execute). Holders represent common policy....
You have distinct sources ( properties, system, classpath ). If you want
a pre-build list - just add a helper method that will configure the
common pattern. But the API remain flexible for the general case and
extensible.
addSource( DiscoverSource )
addDefaultSources() -> will load SystemProperties, PropertiesFile,
ClassPath in this order.
> BTW, here is where Iterators are useful. If I return a [] for the whole
> list of classes, then I have to process all names before returning to
> user. This is a killer if my logic returns the Nth class it finds (not
I see no difference. Can you give an example ? You return a Resource[],
not a list of Classes - at least in the generic method. In the specialized
method that returns classes[] - it's the same thing, it's trivial to
create an equivalent List or Itarator around the array.
> Performance comes from simplicity of design, yes, but also by-design.
Yes - but you'll have to explain how your design is helping performance.
We have a list of places to search, and it doesn't matter too much
how you set this list. Caching and object reusing is possible in both
cases.
> I agree that your proposal *would* be more performant for worst-case
> scenarious where you will be looking at everything that Discovery returns.
> My model is going to be more performant in the median case, and if I can
> save even ONE file read or class load, then it's likely that the time lost
> in overhead to iterators etc. is more than offset.
You can brake the process when you find the first result, if you want
only one. If you want all results - you have no other way than to
look for all.
As for 'more performant' / 'less performant' - what have you used
to determine that ?
I think the performance is a false track on this discussion - even if
the discovery is in the critical path ( which I don't think will be
very common ), I am confident both models can be optimized and will use
similar alghoritms.
> >You create a DiscoverSource, addClassLoaders, and reuse this in
> >different contexts. That's identical with a ClassLoaders object
> > and using it to construct DiscoverSources ( as param in
> >the constructor ).
>
> Not all Discoverers need the classloader. Remember also that the set of
> ClassLoaders represents a policy that might be shared by different
> instances of Discovers... Maybe you have an example?
Of what ? The set of ClassLoaders can be constructed using a ClassLoaders
object or just addClassLoader() on the Discoverer. It's the same info.
And if a class loader is not available or needed by a discoverer - it
will just be ignored or not used.
> >Then just use commons-logging, and we'll deal with the build
> >problems when c-l starts using discovery.
>
> OK with this, I can remove the copied classes. I'll leave the behaviour,
> because I don't want discovery initiating a call to LogFactory if, one
> day, LogFactory calls discovery... I want discovery to have resolved all
> Log implementations at one-level before those classes get used by
> LogFactory...
Let's deal with this when we have to. I think this is an implemnetation
detail, and we can avoid the recursion.
> >Or ( even better IMO ) - use a Listener interface instead
> > of log, so you can be finely notified by all events in the
> >discovery process ( and may even react !).
>
> Hmm.. this maybe another way to handle defered processing..
> to many choices... trix are for kids!
:-)
It may be a very flexible way to extend the model - it's not
only for logging, but it can be a generic hook mechanism.
( Interceptors ? )
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by Richard Sitze <rs...@us.ibm.com>.
>"Type-safe polymorphism" ? If that requires "Resource IS_A name",
>then we should loose it. Why would you need it ? Just remove
ResourceName,
>use String - and pass the string if you want the name, the real
>resource if you want the 'named object'.
>
>There is no 'polymorphism' between a name and a named resource.
My goal was to allow use of a Resource or ResourceClass as a
ResourceName... Since DiscoverResource and/or ResourceClass don't map a
name to a new name (or are not intended to) as DiscoverResourceName does,
this may not be as usefull as I thought.
Let me think on this and play around with it... I will either come up with
a specific scenario, or I'll either remove it.
>
>> >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.
>
>Again, what I disagree with is the arbitrary type distinction between
>Resource and ResourceClass. At least I don't see them as distinct,
>the real information is a string in the META-INF or some property
>file, and it can be used to construct a class or just to display
>a selection box ( say 'select JDBC driver' or 'select xslt processor' ).
>Same info can be used either way. The user is required anyway to
>know what he is looking for - and the name and where it should look
>and in what order. It is not absurt do expect him to know if he's
>looking for a class that he wants to instantiate or just a class.
But is my (generic) method getting a (file) resource or a class?
The parameter type communicates to me & my users what I'm expecting: a
class.
>And I don't agree you 'know' you can load it. You may know that
>the class is defined in META-INF/services, and you may even know
>that the class is in the classpath - but you may not be able to
>load it or instantiate it ( for example because of missing
>dependencies ).
If it's a ResourceClass from a ResourceClassIterator, it's loadable by the
ClassLoader. I *know* I can load it (barring security exceptions.. I/O
problems, etc).
Ahh.. perhaps a bit of mind-sync will help here. With current scheme we
have DiscoverServiceNames... no longer do I have a DiscoverService
(though it would be easy to add). DiscoverServiceNames returns (for now)
ResourceNameIterator, not ResourceIterator. **There is not a guarantee
that a class of a given name exists or can be loaded until is goes through
DiscoverClasses** DiscoverClasses has a
findResourceClasses(ResourceNameIterator) which will resolve a 'list of
names into valid classes.
>And any 'resource' can be used as either a class or a string.
>Displaying the list of available drivers is a valid use for the
>discovered resource - and the same discovery can be used to
>instantiate.
>
>> >Or even better - return Resource[].
>>
>> If I knew how to defer file I/O, ClassLoader.getResource(), etc.
>> then I would much prefer this also.
>
>Resource can do the deferal. ( i.e Resource.getXXX would do the
>operation, instead of putting it in the constructor ).
That would work for some cases, but not all. Maybe my answer is to go
ahead and use [] in the general case, but provide a ResourceIterator for
those that don't. Now that I have all the logic mapped out, I'll go back
through & see exactly which ones still benefit from an Iterator...
>> >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.
>
>Then use the bean model and reuse the bean.
Can't. I've got multiple discoverers strung together:
- DiscoverNamesInSystemProperties
- DiscoverNamesInDictionary
- DiscoverServiceNames [extends DiscoverNamesInFile,
which requires a set of class loaders]
All of which get sent through DiscoverClasses [requires class loaders]
A model that requires that the list be built up in each case (and how many
OTHER discovery sequences might I build up in a system?) just seems like
unnecessary work (code to write) for user and for Discovery (code to
execute). Holders represent common policy....
BTW, here is where Iterators are useful. If I return a [] for the whole
list of classes, then I have to process all names before returning to
user. This is a killer if my logic returns the Nth class it finds (not
necessarily the first name or the first class). Performance comes from
simplicity of design, yes, but also by-design.
I agree that your proposal *would* be more performant for worst-case
scenarious where you will be looking at everything that Discovery returns.
My model is going to be more performant in the median case, and if I can
save even ONE file read or class load, then it's likely that the time lost
in overhead to iterators etc. is more than offset.
>Please trust me on this one - I did a bit of 'performance'
>work ( try tomcat 3.1 and tomcat 3.3 for example ), a simpler
>model and design almost allways leads to better performance in the
>longer term.
>
>> 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.
>
>I don't see any alghoritmic difference. Information can be
cached/recycled
>- there is nothing funamentally slow in a simpler design.
>
>You create a DiscoverSource, addClassLoaders, and reuse this in
>different contexts. That's identical with a ClassLoaders object
> and using it to construct DiscoverSources ( as param in
>the constructor ).
Not all Discoverers need the classloader. Remember also that the set of
ClassLoaders represents a policy that might be shared by different
instances of Discovers... Maybe you have an example?
>> 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.
>
>But there's nothing to loose either. A findFirst() would be
>reasonable - since many use cases require this kind of behavior.
>And the internal implementation can use a
>
>private discoverResources(boolean findFirst) that would stop
>after the first found resource if findFirst==true.
>
>The returned object would be 'lazy', but in findFirst case you'll
>just evaluate it before returning.
>
>
>> >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.
>
>Then just use commons-logging, and we'll deal with the build
>problems when c-l starts using discovery.
OK with this, I can remove the copied classes. I'll leave the behaviour,
because I don't want discovery initiating a call to LogFactory if, one
day, LogFactory calls discovery... I want discovery to have resolved all
Log implementations at one-level before those classes get used by
LogFactory...
>
>Or ( even better IMO ) - use a Listener interface instead
> of log, so you can be finely notified by all events in the
>discovery process ( and may even react !).
Hmm.. this maybe another way to handle defered processing..
to many choices... trix are for kids!
>> - I've copied ONLY the (current) Log interface & LogFactory
>> in Discovery so that we don't have a build dependency on
>> commons-logging.
>
>Duplicating Log and LogFactory is IMO far worse than having
>a build dependency ( or even cross dependency ).
>And if you also factor in the extra complexity...
>
>
>> >> 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.
>
>???
>
>Not sure I understand. You get back a Resource with the URL, loader,
>etc. That will signal that a certain resource is available ( say
> a JDBC driver ). In ant case ( with the current extensions in 'embed')
>it is possible to add more jars to the loader. In addition,
>I will probably add some Manifest-based discovery, and the user
>could use information from the manifest to download the required
>deps.
>
>There are many cases in which the user can do something to load
>the classes ( after discovering the 'resource/driver' is available
>and eventually looking up in manifest what is required ).
Sounds like an extension of DiscoverClasses (which implements behaviour
appropriate to ClassLoader). Maybe I should rename it?
>> 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.
>
>Again - there are very valid and common cases where the 'one' class
>can't be returned at the moment of discovery, but only later.
>
>Costin
>
Great comments, thanks!
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by co...@covalent.net.
On Fri, 30 Aug 2002, Richard Sitze wrote:
> >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.
"Type-safe polymorphism" ? If that requires "Resource IS_A name",
then we should loose it. Why would you need it ? Just remove ResourceName,
use String - and pass the string if you want the name, the real
resource if you want the 'named object'.
There is no 'polymorphism' between a name and a named resource.
> >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.
Again, what I disagree with is the arbitrary type distinction between
Resource and ResourceClass. At least I don't see them as distinct,
the real information is a string in the META-INF or some property
file, and it can be used to construct a class or just to display
a selection box ( say 'select JDBC driver' or 'select xslt processor' ).
Same info can be used either way. The user is required anyway to
know what he is looking for - and the name and where it should look
and in what order. It is not absurt do expect him to know if he's
looking for a class that he wants to instantiate or just a class.
And I don't agree you 'know' you can load it. You may know that
the class is defined in META-INF/services, and you may even know
that the class is in the classpath - but you may not be able to
load it or instantiate it ( for example because of missing
dependencies ).
And any 'resource' can be used as either a class or a string.
Displaying the list of available drivers is a valid use for the
discovered resource - and the same discovery can be used to
instantiate.
> >Or even better - return Resource[].
>
> If I knew how to defer file I/O, ClassLoader.getResource(), etc.
> then I would much prefer this also.
Resource can do the deferal. ( i.e Resource.getXXX would do the
operation, instead of putting it in the constructor ).
> >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.
Then use the bean model and reuse the bean.
Please trust me on this one - I did a bit of 'performance'
work ( try tomcat 3.1 and tomcat 3.3 for example ), a simpler
model and design almost allways leads to better performance in the
longer term.
> 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.
I don't see any alghoritmic difference. Information can be cached/recycled
- there is nothing funamentally slow in a simpler design.
You create a DiscoverSource, addClassLoaders, and reuse this in
different contexts. That's identical with a ClassLoaders object
and using it to construct DiscoverSources ( as param in
the constructor ).
> 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.
But there's nothing to loose either. A findFirst() would be
reasonable - since many use cases require this kind of behavior.
And the internal implementation can use a
private discoverResources(boolean findFirst) that would stop
after the first found resource if findFirst==true.
The returned object would be 'lazy', but in findFirst case you'll
just evaluate it before returning.
> >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.
Then just use commons-logging, and we'll deal with the build
problems when c-l starts using discovery.
Or ( even better IMO ) - use a Listener interface instead
of log, so you can be finely notified by all events in the
discovery process ( and may even react !).
> - I've copied ONLY the (current) Log interface & LogFactory
> in Discovery so that we don't have a build dependency on
> commons-logging.
Duplicating Log and LogFactory is IMO far worse than having
a build dependency ( or even cross dependency ).
And if you also factor in the extra complexity...
> >> 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.
???
Not sure I understand. You get back a Resource with the URL, loader,
etc. That will signal that a certain resource is available ( say
a JDBC driver ). In ant case ( with the current extensions in 'embed')
it is possible to add more jars to the loader. In addition,
I will probably add some Manifest-based discovery, and the user
could use information from the manifest to download the required
deps.
There are many cases in which the user can do something to load
the classes ( after discovering the 'resource/driver' is available
and eventually looking up in manifest what is required ).
> 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.
Again - there are very valid and common cases where the 'one' class
can't be returned at the moment of discovery, but only later.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by Richard Sitze <rs...@us.ibm.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by co...@covalent.net.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by co...@covalent.net.
On Fri, 30 Aug 2002, Richard Sitze wrote:
> >We have:
> >
> >PropertyDiscoverySource
> >ClassLoaderDiscoverySource
> >SystemPropertyDiscoverySource
> >DirPropertySource
> >...
> >
> >All those sources are used by the Discoverer to return Resources.
>
> No.. these (by whatever name) return names (String, ResourceName,
> whatever). That gets fed to DiscoverResources or DiscoverClasses..
IMO it is far better if they return a Resource object, with
all the information that is available.
Each DiscoverySource will find names - but in the process it will
also have a lot of meta information ( including the reference to the
the DiscoverySource itself ).
The Resource object ( including the String name, but also meta info)
can be enhanced by the DiscoverClasses ( or the Interceptor - if you
go this way ), by constructing the class name. A sort of decorator
pattern.
> >I mean:
> >
> > Resource: contains name( i.e. discovered 'thing'), discoverySource
> > helper methods to construct a class ( lazy )
> >
> > Discoverer: an array of DiscoverySource to be searched, each returning
> > one or many Resource
> > methods: Resource findFirst(), Resource[] findAll
> >
> > DiscoverySource: SPI, each source may have additional properties.
>
> I like that direction.
A decorator or Interceptor would add even more flexibility.
DiscoveryInterceptor:
boolean resourceDiscovered( Resource, DiscoverySource )
You register interceptors in the Discoverer and those are called for
each discovered resource. Each interceptor will validate or do some
additional processing on the Resource - and return false if the
Resource shouldn't be included in the final result.
( or a more flexible return code ).
That also takes care of the logging.
Costin
>
> >
> >Costin
> >
> >>
> >>
> >> *******************************************
> >> Richard A. Sitze
> >> IBM WebSphere WebServices Development
> >>
> >>
> >> Richard,
> >>
> >> Can you think of some cases where we may have a different kind of
> >> Resource ( other than a name or a class ) ? My feeling is that
> >> a discovered resource will fundamentally be a string extracted from
> >> some META-INF directory or some file - with a very common use
> >> as a class name. I can't imagine any 'typical' use of Discovery
> >> for something else.
> >>
> >> My point is that it makes a lot of sense to just have a single
> >> object, Resource. It can be later expanded, but discovery 1.0 would
> >> be much easier to use.
> >>
> >> Also, 2 interfaces/abstract classes - ResourceDiscover and a SPI to be
> >> implemented by all o.a.c.d.resource.names/classes.
> >>
> >> I can live with the current model - I'm just trying to see if
> >> we can get one step simpler.
> >>
> >> Costin
> >
>
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by Richard Sitze <rs...@us.ibm.com>.
>On Fri, 30 Aug 2002, Richard Sitze wrote:
>
>> Properties files are Resources that are not ResourceNames
>
>But they may have names :-)
>
>> Operations are Resource are getClassLoader(), getResource() and
>> getResouceAsStream() [so, Resource is strongly tied to ClassLoader].
>
>Why ? Resource can very well point to a file-system based info.
>What matters IMO is the content - i.e. the name of the driver
>or the available parsers or the task names. The classloader
>is just a helper - and is visible only for advanced users.
>
>
>> The additional operation on ResourceClass is loadClass(), which
internally
>> invokes ClassLoader.loadClass() only if it doesn't already have the
>> Class.. This operation doesn't make sense for the more general
Resource.
>
>IMO the Resource has some content - and that content is in most
>cases the name of a class.
>
>We already discussed that the resource doesn't have to be in the same
>package with its implementation - and I think I found more use-cases
>for that. The loader that found the resource ( in case of 'loader
source')
>is just to inform what the source of discovery was.
>
>We alrady agreed ( and you implemened ) properties and system properties
>based discovery sources. Those have no associated classpath.
>
>We have:
>
>PropertyDiscoverySource
>ClassLoaderDiscoverySource
>SystemPropertyDiscoverySource
>DirPropertySource
>...
>
>All those sources are used by the Discoverer to return Resources.
No.. these (by whatever name) return names (String, ResourceName,
whatever). That gets fed to DiscoverResources or DiscoverClasses..
>
>If you want you can get rid of getClassLoader in Resource, and just
>return getDiscoverySource(). Then the user will check if it was a
>ClassLoaderDS and call getClassLoader() on the source.
>
>Do you think this is a reasonable compromise ?
>
>I mean:
>
> Resource: contains name( i.e. discovered 'thing'), discoverySource
> helper methods to construct a class ( lazy )
>
> Discoverer: an array of DiscoverySource to be searched, each returning
> one or many Resource
> methods: Resource findFirst(), Resource[] findAll
>
> DiscoverySource: SPI, each source may have additional properties.
I like that direction.
>
>Costin
>
>>
>>
>> *******************************************
>> Richard A. Sitze
>> IBM WebSphere WebServices Development
>>
>>
>> Richard,
>>
>> Can you think of some cases where we may have a different kind of
>> Resource ( other than a name or a class ) ? My feeling is that
>> a discovered resource will fundamentally be a string extracted from
>> some META-INF directory or some file - with a very common use
>> as a class name. I can't imagine any 'typical' use of Discovery
>> for something else.
>>
>> My point is that it makes a lot of sense to just have a single
>> object, Resource. It can be later expanded, but discovery 1.0 would
>> be much easier to use.
>>
>> Also, 2 interfaces/abstract classes - ResourceDiscover and a SPI to be
>> implemented by all o.a.c.d.resource.names/classes.
>>
>> I can live with the current model - I'm just trying to see if
>> we can get one step simpler.
>>
>> Costin
>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by co...@covalent.net.
On Fri, 30 Aug 2002, Richard Sitze wrote:
> Properties files are Resources that are not ResourceNames
But they may have names :-)
> Operations are Resource are getClassLoader(), getResource() and
> getResouceAsStream() [so, Resource is strongly tied to ClassLoader].
Why ? Resource can very well point to a file-system based info.
What matters IMO is the content - i.e. the name of the driver
or the available parsers or the task names. The classloader
is just a helper - and is visible only for advanced users.
> The additional operation on ResourceClass is loadClass(), which internally
> invokes ClassLoader.loadClass() only if it doesn't already have the
> Class.. This operation doesn't make sense for the more general Resource.
IMO the Resource has some content - and that content is in most
cases the name of a class.
We already discussed that the resource doesn't have to be in the same
package with its implementation - and I think I found more use-cases
for that. The loader that found the resource ( in case of 'loader source')
is just to inform what the source of discovery was.
We alrady agreed ( and you implemened ) properties and system properties
based discovery sources. Those have no associated classpath.
We have:
PropertyDiscoverySource
ClassLoaderDiscoverySource
SystemPropertyDiscoverySource
DirPropertySource
...
All those sources are used by the Discoverer to return Resources.
If you want you can get rid of getClassLoader in Resource, and just
return getDiscoverySource(). Then the user will check if it was a
ClassLoaderDS and call getClassLoader() on the source.
Do you think this is a reasonable compromise ?
I mean:
Resource: contains name( i.e. discovered 'thing'), discoverySource
helper methods to construct a class ( lazy )
Discoverer: an array of DiscoverySource to be searched, each returning
one or many Resource
methods: Resource findFirst(), Resource[] findAll
DiscoverySource: SPI, each source may have additional properties.
Costin
>
>
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development
>
>
> Richard,
>
> Can you think of some cases where we may have a different kind of
> Resource ( other than a name or a class ) ? My feeling is that
> a discovered resource will fundamentally be a string extracted from
> some META-INF directory or some file - with a very common use
> as a class name. I can't imagine any 'typical' use of Discovery
> for something else.
>
> My point is that it makes a lot of sense to just have a single
> object, Resource. It can be later expanded, but discovery 1.0 would
> be much easier to use.
>
> Also, 2 interfaces/abstract classes - ResourceDiscover and a SPI to be
> implemented by all o.a.c.d.resource.names/classes.
>
> I can live with the current model - I'm just trying to see if
> we can get one step simpler.
>
> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by Richard Sitze <rs...@us.ibm.com>.
Properties files are Resources that are not ResourceNames
Operations are Resource are getClassLoader(), getResource() and
getResouceAsStream() [so, Resource is strongly tied to ClassLoader].
The additional operation on ResourceClass is loadClass(), which internally
invokes ClassLoader.loadClass() only if it doesn't already have the
Class.. This operation doesn't make sense for the more general Resource.
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
Richard,
Can you think of some cases where we may have a different kind of
Resource ( other than a name or a class ) ? My feeling is that
a discovered resource will fundamentally be a string extracted from
some META-INF directory or some file - with a very common use
as a class name. I can't imagine any 'typical' use of Discovery
for something else.
My point is that it makes a lot of sense to just have a single
object, Resource. It can be later expanded, but discovery 1.0 would
be much easier to use.
Also, 2 interfaces/abstract classes - ResourceDiscover and a SPI to be
implemented by all o.a.c.d.resource.names/classes.
I can live with the current model - I'm just trying to see if
we can get one step simpler.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Take III
Posted by co...@covalent.net.
Richard,
Can you think of some cases where we may have a different kind of
Resource ( other than a name or a class ) ? My feeling is that
a discovered resource will fundamentally be a string extracted from
some META-INF directory or some file - with a very common use
as a class name. I can't imagine any 'typical' use of Discovery
for something else.
My point is that it makes a lot of sense to just have a single
object, Resource. It can be later expanded, but discovery 1.0 would
be much easier to use.
Also, 2 interfaces/abstract classes - ResourceDiscover and a SPI to be
implemented by all o.a.c.d.resource.names/classes.
I can live with the current model - I'm just trying to see if
we can get one step simpler.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>