4 ms·
Maybe I'm misunderstanding your point -- by "do not log," do you mean do not call logging statements in a logging library's API, or simply do not force a concre
by empthought 10y ago
Maybe I'm misunderstanding your point -- by "do not log," do you mean do not call logging statements in a logging library's API, or simply do not force a concrete implementation of a logging library? I understand and agree with the second one completely, but the first one seems unrealistic.
I can't see how the Apache httpclient library could sanely "return" the different state transitions and pieces of data that are logged in its wire-level logging, but this is certainly a case where the logging statements are welcome.
- marcosdumay 10y agoYes, if you created a framework, that will call your code, yes, it can log. It can also provide a logger implementation, or request one from you, whatever it deems better, and your code must comply. But a library, that your code will call, must not log. Ever. That includes any portion of a framework that you have to call, but it using services upper on the stack can make this rule hard to see. It must not include a logger implementation, and not call any global logger supplied from you. It seems we are arguing over the definition of those two cases.
- empthought 10y agoSo in the case of Apache HTTPClient (which I would call a library), are you saying that it is a design flaw that it provides logging statements of its internals, when provided the proper configuration/logging implementation? If so, I would have to disagree based on pragmatic grounds, unless you have another credible way to acquire the information present in http wire logging or connection pool events, for example.