commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: [discovery] Vote II, are we ready for RC1?
Date Fri, 16 Aug 2002 02:40:48 GMT
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>


Mime
View raw message