You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by rs...@us.ibm.com on 2002/08/16 00:26:13 UTC
[discovery] Vote II, are we ready for RC1?
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>
*******************************************
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] Vote II, are we ready for RC1?
Posted by co...@covalent.net.
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>
> >
> > *******************************************
> > 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>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery] Vote II, are we ready for RC1?
Posted by co...@covalent.net.
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>
>
> *******************************************
> 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>