ما الأمر مع تسجيل الدخول إلى Java؟[مغلق]

Question

لماذا يستخدم المرء إحدى الحزم التالية بدلاً من الأخرى؟

• تسجيل جافا
• تسجيل العموم
• Log4j
• SLF4j
• تسجيل الدخول مرة أخرى

Answer 1

بالترتيب الزمني لمظهر واجهة برمجة التطبيقات (على حد علمي):

• Log4j لأن معظم الأشخاص يستخدمونه (في تجربتي)
• تسجيل العموميات لأن المشاريع مفتوحة المصدر تستخدمه (حتى تتمكن من التكامل مع أي إطار عمل تسجيل يتم استخدامه في الحل المتكامل)؛صالح بشكل خاص إذا كنت API/Framework/OSS وتعتمد على الحزم الأخرى التي تستخدم Commons Logging.
• تسجيل العموم لأنك لا تريد "التأمين" على إطار عمل تسجيل معين (لذا بدلاً من ذلك تقوم بالتأمين على ما يوفره لك تسجيل العموم بدلاً من ذلك) - لا أعتقد أنه من المعقول أن تقرر استخدام هذه النقطة كسبب.
• تسجيل جافا لأنك لا تريد إضافة جرة إضافية.
• SLF4j لأنه أحدث من تسجيل العموم ويوفر تسجيلًا ذو معلمات:

---

logger.debug("The entry is {}.", entry);
//which expands effectively to
if (logger.isDebugEnabled()){
    // Note that it's actually *more* efficient than this - see Huxi's comment below...
    logger.debug("The entry is " + entry + "."); 
}

• Logback لأنه أحدث من log4j، ومرة ​​أخرى، يدعم التسجيل ذو المعلمات، لأنه ينفذ SLF4j مباشرة
• SLF4j/Logback لأنه مكتوب بواسطة نفس الشخص الذي قام بكتابة log4j، لذا فقد جعله أفضل (وفقًا لـ كين ج - شكرًا.يبدو مناسبًا عند النظر إليه منشوراتهم الإخبارية السابقة)
• SLF4j لأنهم ينشرون أيضًا محول log4j لذا لا يتعين عليك "تبديل" log4j في الكود الأقدم - فقط اجعل log4j.properties يستخدم SLF4j وتكوينه

Answer 2

أجد أن تسجيل الدخول في Java ليكون مربكًا وغير متسق وموثقة بشكل سيء وخاصة العشوائية. علاوة على ذلك ، هناك قدر كبير من التشابه بين أطر التسجيل هذه مما يؤدي إلى ازدواج الجهد ، والارتباك حول بيئة التسجيل التي أنت فيها بالفعل. مضاعف بيئات التسجيل في وقت واحد ؛ (على سبيل المثال ، قد تستخدم Hibernate log4j ، و tomcat java.util.logging). تهدف Apache Commons إلى سد أطراف تسجيل مختلفة ، ولكن في الحقيقة تضيف المزيد من التعقيد. إذا كنت لا تعرف هذا في وقت مبكر ، فهذا محير تمامًا. لماذا لا يتم طباعة رسائل السجل الخاصة بي إلى وحدة التحكم ، وما إلى ذلك؟ أوه لأنني أنظر إلى سجلات Tomcat ، وليس Log4J. إضافة طبقة أخرى من التعقيد ، قد يكون لخادم التطبيق تكوينات تسجيل عالمية قد لا تتعرف على التكوينات المحلية لتطبيق ويب معين. أخيرًا ، كل أطراف التسجيل هذه معقدة للغاية. كان تسجيل الدخول في Java فوضى غير منظمة تاركة مطورين مثلي محبطًا ومرتبكًا.

لم يكن لدى الإصدارات المبكرة من Java إطار تسجيل مدمج يؤدي إلى هذا السيناريو.

Answer 3

There's one important point that wasn't mentioned before:

SLF4J (and both Logback and LOG4J as the logging backend) have support for a so called Mapped Diagnostic Context (MDC, see javadoc and documentation).

This is essentially a thread-local Map<String,String> which you can use to add additional context information to your logging event. The current state of the MDC is attached to every event.

This can be incredibly useful if you put stuff like the username and the URL of the request (in case of a webapp) into it. This can be done automatically using a filter, for example.

Answer 4

See also answers to the question What are the best practices to log an error?, especially:

• There are some potential classloading issues with Commons Logging.

• Log4J and SLF4J were developed by the same person, learning from issues found in practice with Log4J.

Answer 5

In our company project we use LOG4j and it is very easy to use like Stephen showed in his example. We also have written our own pattern classes for LOG4j so you can create your own output file schemas. You can describe how your log file should look like. It is possible to enhance the original log4j classes.

All LOG4j properties you can change in a log4j.properties file, so you can use different files for different projects.

Java logging is not my favorit, but this could be because i use log4j from the beginning.

Answer 6

The Commons Logging overview gives the reason for its existence: logging from library code, when you have no control over the underlying logging framework. Very important for the various Apache projects, which will be linked into outside applications. Perhaps not so important for internal IT projects, where you have complete control.

That said, I write to Commons Logging, as do many of the other developers I know. The reason is to minimize mental baggage: you can change projects or jobs, and not have to learn a new framework (provided the new job/project also uses CL, and/or you can convince them to move to it).

Also, there is some value to creating your own wrappers around whatever framework you use. As described here, I like to use a LogWrapper object to provide custom stringification (important), and minimize the visual clutter of logging statements (less important).

Answer 7

Generally I would default to using Log4J.

I would use Java Logging if I didn't mind a dependency on Java 1.4 but I would still use Log4J in preference.

I would use Commons Logging if I was enhancing something that already used it.

Answer 8

I would suggest creating a thin logging facade that can write to any of the logging frameworks, at which point the choice of backing engine become pretty much a moot point.