commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: [discovery] Vote II, are we ready for RC1?
Date Fri, 16 Aug 2002 18:01:57 GMT
On Fri, 16 Aug 2002 rsitze@us.ibm.com wrote:

> <sigh> (impatience... deep breath...)  you are probably correct that I'm 
> pushing on this to hard...

I think it is too important to not do it right, and right takes time :-)
If you need the functionality - you can just copy the current code and use
it, or make a milestone release, but it is far too early for freezing 
APIs.


> What I've got, or rather where I'm going, is a framework off of which I 
> can hang the types of things you want.  I think your suggestion is fine, I 
> should certainly be able to adapt the framework to your 'strategies'.

Carefull with the words :-) Avoid the f-word.

>           org.apache.commons.discovery - contains most generally useful 
> classes (not necessarily useful by power users such as yourself!)  I think 
> this covers 80% of what an application developer might want to do.  Feed 
> back from other users (user?) would be welcome.  I think that, whatever 
> else you do, this is starting to stablize.

My only problem is the complexity of the code - it is trying to do too
much, and it's missing the point !


> The logic you are looking for goes well beyond my simple case, so why 
> don't you take a stab at that layer.  If you don't like 'strategy', then 
> put it in your own package for the moment.  I get to work it over :-), and 
> we'll see how to adapt to it.  I do have a concern with performance with 
> using 'getResources', so I'd like to maintain both the poly-form and the 
> mono-form of the interface.  It would be an improvement (but still a cost, 
> simply because getResources takes more than getResource) if your methods 
> returned an Enumeration instead of an array, and deferred resolution of 
> the 'next' until it was asked for.
> 
> All that aside, I'm always open to whole-sale reorganization (at this 
> early stage) if you have a good proposal.


Discovering the services is the primary purpose of the package - 
instantiating classes or defining order or properties are non-core.
In the current version the 'primary function' is too obscured by
helpers. 

And discovery is the real complex thing, where people would actually 
benefit from a commons package. Creating Class.forName or Instances or
looking for Properties is well-known and easy.

Instead of getting into pluggable Strategies - it is much better
to just return all the found services and let the user pick. This
opens the door for some extremely important use cases - like selecting
the best driver for your code. 

As for 'power user' - if the API is simple, you don't need a power
user. Just return an ServiceInfo[], and let the user select what
is best instead of specifying a comples plugable Strategy - and
all the 'power use' is iterating and selecting with some simple
code what you need.


Costin 

> 
> <ras>
> 
> 
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development
> 
> 
> Ok, I looked more at the code - and I think it would benefit 
> a _lot_ if it would be layered.
> 
> One thing is clear IMO - this is not a simple problem. And combining
> too many things is not good. 
> 
> What about this ( and I can help with the implementation ):
> - we have one package that deals _only_ with META-INF/services.
> 
> - a separate package will do all the extra stuff that you need
> ( create instances, etc ).
> 
> For the first package:
> 
> class SeriviceDiscoverer {
>     void addClassLoader(ClassLoader)
>     ServiceInfo[] findServices(String);
> }
> 
> You create an instance, add all the loaders in any order you want, then
> call findServices. 
> 
> ServiceInfo will contain ClassLoader that was used, name, URL.
> 
> It'll use ClassLoader.getResources() ( for 1.2+ ) and introspection/hacks
> to deal with JDK1.1 ( antClassLoader has a findResources - and it can be 
> changed to support this ).
> 
> getResources(META-INF/sercices/name) will return a list of URLs where 
> the class names can be read. We don't need to instantiate it - just 
> create the ServiceInfo and save the information.
> 
> Again - no extra 'Policy' or extra API, just plain and simple find
> all the resources named "META-INF/sercices/org.apache.tools.ant.Task" 
> ( or whatever ) and read the content as a list of drivers.
> 
> The list will be sorted by the order we find the resources - 
> and the order of loaders. If you want threadLoader to be searched
> first - you add it first.
> 
> A nice thing is that on top of this ( I think very simple ) API you
> can build more complex things, like what you seem to need.
> 
> No class will be created or searched for - the caller can check 
> if the class exist or find 'best fit', etc. 
> 
> This could also be used for finding the 'best' driver - or a driver
> that fits certain criteria. 
> 
> Right now JAXP returns the 'first' - but with this mechanism you 
> can do much more, instantiate all parsers in classpath and find 
> which one supports schema - for example - or a specific version. 
> 
> Let's not hurry too much to release and find the best solution. 
> To me the current one seems too complex, and part of the complexity
> is due ( IMO ) of trying to do too much. Plus the fact that it is 
> very difficult to write an API to select a particular driver with
> a flexible policy and all that - it is much simpler to let the 
> caller select from a list of choices. 
> 
> Costin
> 
> 
>  
> 
> 
> rsitze@us.ibm.com wrote:
> 
> > During your review, take a look at
> > discovery.strategy.DiscoverStrategy.discoverClassNames().  You can use
> > that directly...  Seems like a starting point to build up your next 
> step.
> > 
> > I see your point with ant... We have divergent (but not contradictory)
> > directions.  At one end, I'd prefer NOT to find all strings (but I coded
> > it because you mentioned it in an earlier note), JUST the first one.  If
> > the first is not available, then (the theory) was throw an exception,
> > something is configured incorrectly (and you are about to give me a
> > use-case to contradict that, aren't you :-).  Even IF we keep going and 
> IF
> > we are going to load the class internally, I would want to cycle through
> > 'find-string, load-class, find-next, load-next' etc  to minimize
> > performance impact (classloaders can have a significant runtime cost :-(
> > ).
> > 
> > RE: your first request below, seems to me that once I've got loader/URL,
> > I've already got the Class (unless you've got an 'in' with the
> > classloaders that I'm not aware of).  And I'm NOT sure how you get the
> > URL!
> > 
> > RE: merging constructors/methods: which classes are you talking about?
> > 
> > <ras>
> > 
> > *******************************************
> > Richard A. Sitze
> > IBM WebSphere WebServices Development
> > 
> > 
> > Actually... I'm wrong about String[].
> > 
> > I think the 'generic' return type should be DiscoveryResult[], with:
> > 
> > class DiscoveryResult {
> >   String name; // name of
> >   ClassLoader loader; // loader used to find the .jar
> >   URL location; // path the the jar containing the entry
> > }
> > 
> > What would you think about merging the methods/constructors and
> > having only the most generic one ( and 'null' used for unknown
> > values ) ? It would make things easier to read IMO.
> > 
> > The DiscoveryResult can also simplify the life if you want to
> > create the class or instance later.
> > 
> > Costin
> > 
> > 
> > On Thu, 15 Aug 2002 costinm@covalent.net wrote:
> > 
> >> 
> >> A quick comment - still need to review the rest:
> >> 
> >> What happens if you have multiple implementations ? Either the manifest
> > is
> >> found in 2 jars, or one file contains multiple lines ?
> >> 
> >> For jaxp and logging - the use case is obviously a single driver, in
> >> the specified order. But the spec allows for multiple drivers to
> >> be found.
> >> 
> >> Use case: ant using discovery to locate tasks ( assuming the name
> >> associated with a task can be determined from task or some 
> conventions).
> >> Each jar can contain one or more ant tasks - you want to return
> >> an array.
> >> 
> >> Also in this use case: some of the tasks may depend on jars that
> >> may be added dynamically, later. For example junit task depens
> >> on junit.jar, which is not available at the time junit task
> >> is discovered. The model in ant is to instantiate ( and do
> > Class.forName)
> >> very late - before execution. Discovery doing Class.forName prevents
> >> that. So we need a method returning String[].
> >> 
> >> And finally ( same use case ): ant supports the notion of 'adapters' -
> >> the class may not extend Task ( the abstract class we look for ) - but
> >> still be valid tasks using the task adapter. That would work with
> >> the current API, but the wording ( the result implements ... ) doesn't
> >> fit.
> >> 
> >> 
> >> 
> >> Costin
> >> 
> >> 
> >> 
> >> 
> >> On Thu, 15 Aug 2002 rsitze@us.ibm.com wrote:
> >> 
> >> > I'm once again ready to push out an RC1.  I could ask for comments,
> > but
> >> > that doesn't seem to generate as much interest as calling for a vote!
> > So,
> >> > here is my
> >> > 
> >> > +1   for releasing commons-discovery RC1
> >> > 
> >> > ****
> >> > 
> >> > I believe I've resolved the serious issues.  A few highlights of
> >> > significant changes:
> >> > 
> >> > - removed life-cycle support.  We can add features to help support
> > later,
> >> > if someone so desires (via events).
> >> > 
> >> > - a reasonable (probably still too many) set of 'find' and
> > 'newInstance'
> >> > methods.  [If you want more control, use Environment, SPInterface, 
> and
> > 
> >> > ImplClass directly]
> >> > 
> >> > - moved 'don't-depend-on-me' code OUT of discovery & discovery.base
> >> > packages, into discovery.tooling package.
> >> > 
> >> > - removed caching-by-groupContext.  I still use the groupContext to
> >> > qualify various properties & property file names, but the more I 
> think
> > 
> >> > about it, the more I don't want it in the cache yet.  It's easier to
> > add
> >> > than remove later... so it's gone.
> >> > 
> >> > <ras>
> 
> 
> 
> 
> --
> 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>
> 
> 


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