commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: [discovery] code/design review [was Re: The exegesis]
Date Wed, 14 Aug 2002 18:30:10 GMT
On Wed, 14 Aug 2002, Joe Germuska wrote:

> It strikes me that if the majority of expected users are going to be 
> calling class.newInstance, then factoring that out into discovery is 
> reasonable design, rather than having that code duplicated again and 
> again.

Having a class.newInstance() is probably ok.

BTW, a quote from the jar specification ( the part on service ):

" A service is represented by an abstract class. A provider of a given 
service contains one or more concrete classes that extend this service 
class with data and code specific to the provider. This provider class 
will typically not be the entire provider itself but rather a proxy that 
contains enough information to decide whether the provider is able to 
satisfy a particular request together with code that can create the actual 
provider on demand. The details of provider classes tend to be highly 
service-specific; no single class or interface could possibly unify them, 
so no such class has been defined. The only requirement enforced here is 
that provider classes must have a zero-argument constructor so that they 
may be instantiated during lookup. "


One important note: the discovery is _not_ for a single-result. JAXP and
logging are particular cases where a single 'service provider' is needed
and the selection is done by a defined find-first mechanism.

I think the 'core' method should return a list ( array ) - eventually
sorted by the discovery order.


> Do I take it that you consider even the instantiation part of life 
> cycle management best left to another package with a more complete 
> process?

Actually I think it is best left to the caller - most likely the 'service
manager', the one asking for a service provider. It is most likely that 
each will have it's own specifics for initialization and configuration.


> It's certainly not something I would make a big fuss about if it gets left out.

I'm not going to make a big fuss about having it as a helper - as long
as it doesn't use Properties or other non-discovery-related contracts.


Costin


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