hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <mbe...@gmail.com>
Subject Re: [http-common][request for comments] serivce locator vs dependency injection
Date Wed, 18 May 2005 02:23:36 GMT
Most of my experience has been with DI.  Given that and the likely
class loading issues with SL I think DI is probably best for us.

Mike

On 5/16/05, Oleg Kalnichevski <olegk@apache.org> wrote:
> 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
> 
>

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


Mime
View raw message