The one comment I have to add to the mix - the service locator option is complicated enough to do well that there is separate commons-discovery project.
Not to mention if you don't set the Thread.getContextClassLoader(), it doesn't work. So I'd lean towards constructor based dependency injection. -Eric. Oleg Kalnichevski 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: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
