3 ms·

Okay, now we're getting somewhere, but as someone who has used Java more client-side than server-side, I'm not familiar with the problems everyone's else been t

by koko775 14y ago

Okay, now we're getting somewhere, but as someone who has used Java more client-side than server-side, I'm not familiar with the problems everyone's else been through. I would love for you to enlighten me, if you could! Also, what would you substitute in place of StaticLoggerBinder? It did strike me as somewhat janky to rely on a class with a matching name and class just existing.

bborud 14y ago
The problem is not software. The problem is people. Rather than trying to explain the problem (which most people who work on logging struggle to see), let me outline how you determine when the problem is either solved or absent. The problem is solved when people like me (a hands-on system architect who writes code and tries to make decisions on behalf of a number of developers) do not have to think about logging APIs, facades or backends anymore. When nobody in my organization has to spend time trying to resolve the conflicts that arise from different logging technologies (and different versions of same technologies) being in use in the same system. We have an example of that in Java: the collection classes. For most bread-and-butter uses Java has List, Map and Set types that people can just use. They are well designed, well documented and you can count on them to be available at no extra cost. It is unusual for a non-mad() Java programmer to feel the need to introduce extra dependencies for simple lists, sets, maps etc. You most likely are not going to feel the pain of logging chaos if you are writing a single application. If you try to make decisions on behalf of 50+ projects, some of which rely on an obscene number of libraries, that pain will manifest itself every day and you will re-live the same pointless discussions and get the same pointless advice over and over and over. Hope this sheds some light on why I think what I think. () there are idiots who depend on third party implementations where the types in J2SE would suffice.

by koko775 14y ago

bborud 14y ago

The problem is not software. The problem is people. Rather than trying to explain the problem (which most people who work on logging struggle to see), let me outline how you determine when the problem is either solved or absent. The problem is solved when people like me (a hands-on system architect who writes code and tries to make decisions on behalf of a number of developers) do not have to think about logging APIs, facades or backends anymore. When nobody in my organization has to spend time trying to resolve the conflicts that arise from different logging technologies (and different versions of same technologies) being in use in the same system. We have an example of that in Java: the collection classes. For most bread-and-butter uses Java has List, Map and Set types that people can just use. They are well designed, well documented and you can count on them to be available at no extra cost. It is unusual for a non-mad() Java programmer to feel the need to introduce extra dependencies for simple lists, sets, maps etc. You most likely are not going to feel the pain of logging chaos if you are writing a single application. If you try to make decisions on behalf of 50+ projects, some of which rely on an obscene number of libraries, that pain will manifest itself every day and you will re-live the same pointless discussions and get the same pointless advice over and over and over. Hope this sheds some light on why I think what I think. () there are idiots who depend on third party implementations where the types in J2SE would suffice.