Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why a Logging Framework Should Not Log

russet.org.uk

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Why a Logging Framework Should Not Log

#51

Post by marcosdumay »

empthought wrote: post #48
marcosdumay wrote: post #44

Earlier quoted context omitted.

If it's not an error condition, you return it. Libraries must not do any covert IO (in fact, any covert anything). A logging library is the only one that should log, and not their own messages. They may write into some main application supplied collector, if it is not global, or if it is clearly handled as a message passing API. The Java way is simply bad.

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…

Yes, 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.

Re: Why a Logging Framework Should Not Log

#52

Post by empthought »

marcosdumay wrote: post #51
empthought wrote: post #48

Earlier quoted context omitted.

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…

Yes, 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…

So 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.

Re: Why a Logging Framework Should Not Log

#53

Post by paulmd »

puppetmaster3 wrote: post #50
paulmd wrote: post #12

Earlier quoted context omitted.

Yeah, it's the exact situation described in that XKCD: "There are 14 competing standards! Let's create one that is perfect for everyone's use-case!" "There are 15 competing standards..." https://xkcd.com/927/ And, as you noticed, pretty much every Java project will reach a point where it has to deal with all four-ish of the major logging frameworks. Some module, somewhere, will include an Apache dependency and then y…

I doubt that you have used the SLF4J bridge in any realsitic situation, else you would not say that it works.

I have and it works fine.

Re: Why a Logging Framework Should Not Log

#54

Post by puppetmaster3 »

paulmd wrote: post #53
puppetmaster3 wrote: post #50

Earlier quoted context omitted.

I doubt that you have used the SLF4J bridge in any realsitic situation, else you would not say that it works.

I have and it works fine.

I don't believe you.

Even the docs say it does not work w/ multiple loggers. But I'm not here to teach, good luck.

Re: Why a Logging Framework Should Not Log

#55

Post by puppetmaster3 »

bhaak wrote: post #35
puppetmaster3 wrote: post #9

The logging in java is supper idiotic. This is because everyone agrees that Java's logging is shit. So every library uses something else. I have a small project and have 4 logging systems (that I had to integrate). ps: if you are a business person and have an option on this, I don't care for it regardless of your pov.

So how does state-of-the-art logging work these days?

If your libs use multiple loggers, then you are SOL.

Re: Why a Logging Framework Should Not Log

#56

Post by paulmd »

puppetmaster3 wrote: post #54
paulmd wrote: post #53

Earlier quoted context omitted.

I have and it works fine.

I don't believe you. Even the docs say it does not work w/ multiple loggers. But I'm not here to teach, good luck.

You're quite simply wrong - the docs do not say that anywhere.

What they do say is that you are not allowed to route loggers circularly - if you route (for example) JUL through SLF4J, you are not allowed to route that output back to JUL, otherwise messages would never be dumped to output.

Re: Why a Logging Framework Should Not Log

#57

Post by puppetmaster3 »

paulmd wrote: post #56
puppetmaster3 wrote: post #54

Earlier quoted context omitted.

I don't believe you. Even the docs say it does not work w/ multiple loggers. But I'm not here to teach, good luck.

You're quite simply wrong - the docs do not say that anywhere. What they do say is that you are not allowed to route loggers circularly - if you route (for example) JUL through SLF4J, you are not allowed to route that output back to JUL, otherwise messages would never be dumped to output.

That's why I said that you have not used it in anger in production environments. Anyway, good luck.
Post reply on HN