hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ROLWE...@de.ibm.com>
Subject Re: [http-common][request for comments] serivce locator vs dependency injection
Date Wed, 18 May 2005 07:26:02 GMT
Hi Oleg,

I am not familiar with the term "dependent interface",
but I favor a class factory over lookups in META-INF
any time. Same reason as Odi: the settings can be
adjusted at runtime, without repackaging a JAR.

I envision a default implementation for the factory
class that reads the class name for an interface from
HttpParams, to remain consistent with the rest of
HttpClient configuration and parameterization.

When I find the time, I'll check out
http://www.martinfowler.com/articles/injection.html
to learn about DI.

cheers,
  Roland





Oleg Kalnichevski <olegk@apache.org> 
16.05.2005 21:39
Please respond to
"HttpClient Project"


To
HttpClient Project <httpclient-dev@jakarta.apache.org>
cc

Subject
[http-common][request for comments] serivce locator vs dependency 
injection






Folks,

There is one major hurdle to be overcome toward before http-common API
can be declared feature-complete. 

Unlike the old HttpClient 2.0 - 3.0 architecture all major logical
components of the new architecture are now represented by an interface
rather than a concrete class. The purpose of the interfaces is to
enforce a contract between the service and its consumers, not a concrete
implementation. The concrete implementation ideally should be resolved
at the runtime through a service locator mechanism or injected by a
container or manually. Both approaches, SL and DI, are quite common and
usually have pros and cons and I am not entirely which one would serve
us better. Both should be as non-intrusive as possible and must not
require a configuration file

(1) service locator option: names of impl classes are stored in META-
INF/services/ as resource files. 

PROS: I believe this is what generally recommended by Sun
CONS: The resource files are supposed to be read by class loader and
class loaders in non-trivial environments tend to create non-trivial
problems (think commons-logging)

(2) dependency injection option: dependent interface or a class factory
is introduced though a setter or a contractor parameter

PROS: No need to retrieve any data from a file; Compatibility with
popular DI/IoC containers
CONS: Somewhat uglier API

Folks, which option do you see as a more preferable one? Do you see any
other options?

Please let me know what you think

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message