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]
