• P (unregistered)

    You're going to tell me tomorrow logging frameworks are Turing Complete.

  • NULLPTR (unregistered)

    Grrrr. too slow on Null-Pointerin this time...

  • P (unregistered) in reply to NULLPTR

    :trollface:

  • (nodebb)

    This is actually something some Python interpreters do best: they capture all of the local variable and parameter values in the exception stack trace. Neither JVM nor .NET do it.

  • LCrawford (unregistered)

    Repeat after me: "anything Global is bad, very very bad". Or is it perhaps not so bad at times?

  • Michael P (unregistered)

    The real WTF is why Java people think two different parts of one piece of software need to use different solutions to solve the same problem.

  • Torgo (unregistered)

    "If it's stupid and it works then you ship it." clap clap "If it's stupid and it works then you ship it." clap clap "If it's stupid and it works then ignore the way it irks " "If it's stupid and it works then you ship it." clap clap

  • (nodebb) in reply to Torgo

    That tune was playing in my head too hahaha

  • (nodebb)

    I was hoping they'd export the whole MDC HashMap as URI parameters. It would save a lot of typing, and I can't possibly fathom what could go wrong...

  • ooOOooGa (unregistered) in reply to Mr. TA

    Yeah. Making sure that everything gets put into the stack trace is easy enough when everything has public access...

  • (nodebb)

    Mapped Diagnostic Context

  • The MASTer (unregistered) in reply to Torgo

    The MASTer approves

  • Shill (unregistered)

    I'm with Michael P.

    If there was a library that provided a thread local map and both the logging framework and the application happened to use it, nobody would have thought this was a WTF. But because the logging framework happens to include it now it's an issue.

    Although it would be better if they used CloseableThreadContext instead so that the "session" information doesn't carry over into subsequent requests and/or become a memory leak.

  • Paul (unregistered)

    This is the worst WTF this site has ever posted. That looks like a completely sane piece of code that solves a real problem in a maintainable and effective way. Just because a tool was meant for something else doesn't mean you can't use it for other things- right?

  • (nodebb) in reply to ooOOooGa

    There's no such thing as access when stack trace is created by the framework's underlying code.

  • sizer99 (google) in reply to Michael P

    Java people know that the more frameworks you are using the better your code is. If that means you use two different ones that do the same thing, so be it!

  • sizer99 (google) in reply to Paul

    It's a somewhat controlled global, but it's still a global. Passing everything around to everyone and letting anyone modify it is still a bad idea, for the same reasons. It's only a matter of time before one of these routines starts helpfully massaging the data and every other routine touching it goes kaboom.

    Now, is this better than anything else these clowns could have come up with? Possibly so, so it was a relatively good choice for them. But it's still a WTF.

  • Spoil Sport (unregistered) in reply to Torgo

    ...So Noah, he built him, he built him an appy appy, Noah he built him, he built him an appy appy, built it out of. logging frameworks, children of the Lord...

  • Raystorm (unregistered)

    "If it's stupid and it works then you ship it." - I think we have a follow-up to Remy's Law of Requirements about Excel. Remy's law of Releases?

Leave a comment on “A Context for Logging”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article