هل تجد أن java.util.logging كافٍ؟[مغلق]

StackOverflow https://stackoverflow.com/questions/607863

  •  03-07-2019
  •  | 
  •  

سؤال

وفقًا للعنوان، هل تجد إطار عمل تسجيل Java الافتراضي كافيًا لاحتياجاتك؟

هل تستخدم خدمات تسجيل بديلة مثل log4j او اخرين؟إذا كان الأمر كذلك لماذا؟أود أن أسمع أي نصيحة لديك فيما يتعلق بمتطلبات التسجيل في أنواع مختلفة من المشاريع، وعندما يكون دمج الأطر ضروريًا و/أو مفيدًا بالفعل.

هل كانت مفيدة؟

المحلول

التبعيات تسجيل مع حزب المكتبات الثالث

وجافا JDK تسجيل في معظم الحالات ليست كافية في حد ذاته. ومع ذلك، إذا كان لديك مشروع كبير يستخدم متعددة المصادر المفتوحة المكتبات طرف ثالث، سوف تكتشف بسرعة أن الكثير منهم لديهم تبعيات تسجيل المتباينة.

وفي هذه الحالات التي تكون فيها الحاجة إلى المجرد API تسجيل الخاص بك من تنفيذ تسجيل الخاص بك تصبح مهمة. أوصي باستخدام slf4j أو <وأ href = "http://logback.qos.ch/" يختلط = " noreferrer "> logback (ويستخدم API slf4j) كما API الخاصة بك، وإذا كنت ترغب في البقاء مع تسجيل Java JDK، كنت لا تزال يمكن! Slf4j يمكن إخراج إلى العديد من تطبيقات مسجل مختلفة مع أية مشاكل.

وهناك مثال ملموس على فائدته حدث خلال مشروع حديث: كنا بحاجة لاستخدام يبس الجهات الأخرى التي يحتاج log4j، ولكن لم نكن نريد لتشغيل إطارين تسجيل جنبا إلى جنب، لذلك استخدمنا يبس المجمع slf4j log4j المعهد وتم حل المشكلة.

في ملخص، جافا JDK تسجيل ما يرام، ولكن سوف API موحد يستخدم في المكتبات حزبي الثالثة سيوفر لك الوقت في المدى الطويل. مجرد محاولة لتخيل إعادة بيع ديون كل بيان تسجيل!

نصائح أخرى

java.util.logging (jul) لم يكن ضروريًا منذ البداية.فقط تجاهله.

يوليو في حد ذاته لديه السلبيات التالية:

  • في الوقت الذي تم فيه تقديم jul في Java 1.4، كان هناك بالفعل إطار عمل تسجيل راسخ يُستخدم على نطاق واسع:LOG4J
  • مستويات السجل المحددة مسبقًا هي:شديد، تحذير، معلومات، تكوين، دقيق، أدق، أدق.لن أخبرك بما أفكر به شخصيًا بشأن تلك المستويات المحددة مسبقًا لإبقاء هذه الإجابة شبه موضوعية.
  • يمكن تحديد مستويات إضافية.يدعم jul ما يصل إلى 4G من مستويات السجل المختلفة وهو أمر مبالغ فيه قليلاً، IMHO.أقل في بعض الأحيان أكثر.

  • النقطة الأكثر أهمية: إذا كنت تجرؤ على تحديد مستوى السجل الخاص بك، فمن المحتمل أن تواجه مشكلة تسرب الذاكرة!
    لا تتردد في القراءة عن هذا التأثير هنا:

    إنها قراءة مثيرة جدًا للاهتمام حتى لو كنت لا تخطط لاستخدام مستويات مخصصة، راجع للشغل، نظرًا لأن المشكلة واسعة الانتشار ولا تنطبق فقط على jul على الإطلاق.

  • إنه موجود في مساحة الاسم java.* لذا لا يمكن تبادل التنفيذ في وقت التشغيل.وهذا يمنع بشكل فعال توصيله إلى SLF4J بنفس الطريقة الممكنة في حالة commons.logging وLOG4J.الطريقة التي تتم بها عملية التوصيل لـ jul لها تأثير على الأداء.وهذا يجعل إطار عمل التسجيل الأكثر مرونة على الإطلاق.
  • من خلال تقديم jul، عرّفته Sun ضمنيًا على أنه "إطار عمل تسجيل جافا القياسي".أدى هذا إلى اعتقاد خاطئ شائع مفاده أن "مواطن جافا الصالح" يجب أن يستخدم جول في مكتباته أو تطبيقاته.
    والعكس هو الصحيح.
    إذا كنت تستخدم commons.logging أو LOG4j فستتمكن من تبادل إطار عمل التسجيل المستخدم فعليًا، إذا كنت بحاجة إلى ذلك، عن طريق التوصيل إلى SLF4J.وهذا يعني أن المكتبات التي تستخدم إما commons.logging أو LOG4J أو SLF4J يمكنها جميعًا تسجيل الدخول إلى نفس هدف التسجيل، على سبيل المثال.ملف.

أنا شخصيا أقترح استخدام SLF4J+تسجيل الدخول مرة أخرى التحرير والسرد لجميع أغراض التسجيل.يتم تنسيق كلا المشروعين بواسطة Ceki Gülcü، الرجل الذي يقف وراء LOG4J.
SLF4J هو خليفة جدير (ولكنه غير رسمي لأنه ليس من نفس المجموعة) لـ commons.logging.إنها أقل إشكالية من CL لأنها تحل بشكل ثابت الواجهة الخلفية للتسجيل المستخدمة فعليًا.بالإضافة إلى ذلك، فهو يحتوي على واجهة برمجة تطبيقات أكثر ثراءً من CL.
من ناحية أخرى، يعد Logback هو الوريث (غير) الرسمي لـ LOG4J.إنه يطبق SLF4J محليًا لذلك لا يوجد أي حمل ناتج عن أي غلاف.

الآن يمكنك التصويت لي إذا كنت لا تزال تعتقد أنني أستحق ذلك.;)

SLF4J هو طفل جديد. لقد فعلت القليل من العمل معها وانها لطيفة جدا. انها الميزة الرئيسية هي parametrized تسجيل ، مما يعني أنك تفعل هذا: 

logger.debug("The new entry is {}. It replaces {}.", entry, oldEntry);

وبدلا من هذا: 

logger.debug("The new entry is " + entry + ". It replaces " + oldEntry + ".");

ويتم كل ذلك التلاعب سلسلة فقط إذا تم تسجيل بيان الواقع. تبدو أنظف للغاية.

وتجدر الإشارة إلى أن SLF4J هو مجمع مثل المشاعات قطع الأشجار، على الرغم من أنه يدعي أنه أقل عرضة للمشاكل المشتركة classloader قطع الأشجار و.

ونحن نستخدم java.util.logging طوال الوقت. أيضا للمشاريع الكبيرة. وهناك عدد قليل من الأشياء التي يجب أن قرص (مثل التنسيق الافتراضي) ولكن هذا خارج النقطة الحقيقية. أجد عدد من الأطر قطع الأشجار في جاوة وزحف الخصائص التي تنفذ مزعج نوعا ما، ومحرجة نوعا ما للمجتمع جافا. مستوى النقاش religuous حول تسجيل هو علامة مؤكدة على أن ما حدث من خطأ على محمل الجد.

ما يعطي يوليو لك هو API بسيطة ولكنها كافية ومكان واحد لتكوين ما إخراج سجل كنت تريد أن ترى (logging.properties أو JMX ...). ودائما هناك ومستقر.

وجميع التعليمات البرمجية التي تريد تسجيل يجب ان يلتزم بالاتفاقيات القياسية (مستوى الافتراضي هو INFO) وخلاف ذلك لا تفعل أكثر ولكن استخدام قطع الاشجار من اسما ذا معنى (مثل حزمة أو اسم الفئة) وسوف يكون على ما يرام.

واذا لم يكن هناك سبب مقنع لاستخدام شيء خارج JDK I تفضل استخدام ما يتم توفيرها من قبل الشمس.

والعديد من المشاريع التي تستخدم في تسجيل Log4J تم استخدامه قبل "القياسية" API تسجيل موجودة.

ومرافق تسجيل JDK لها على دائما تم ما أنا في حاجة إليها للقيام - أبدا لديه مشكلة مع ذلك.

للي، هي ضرورية وليست مرغوبة أدوات قطع الأشجار طرف ثالث.

وكنت غير قادر على معرفة كيفية السيطرة على مستوى تسجيل الفئات الفردية في إطار java.util.logging، وهو أمر ممكن في log4j. إذا أواجه صعوبة في تشخيص الخلل أو هناك فئة ارتفاع حركة المرور الذي يسجل المعلومات الهامة، يمكنني تغيير مستوى لفئة واحدة لتسجيل المزيد وترك بقية صفوفي هادئة نسبيا.

وN.B. يمكن أن يكون ذلك لم أتمكن من معرفة كيفية القيام بذلك، أو java.util.logging قد تغيرت منذ حاولت.

وjava.util.logging جميلة ولكن لايوجد التكوين التي التقطت افتراضيا من CLASSPATH. وهذا هو بالأحرى نقطة الألم بالنسبة لنا كما لدينا العديد من عمليات الانتشار التي لا تشارك تكوينات قطع الأشجار وهو فوضوي وليس للقيام بذلك في j.u.l.

حاليا لا يجري تطويرها

وLog4j كثيرا إذا كان هناك حاجة للتنمية على logback الخلفية جزء وفي لحظة الخيار الأكثر ديناميكية في رأيي.

و(التحذير: المشاركة في بعض تنمية غامضة من slf4j وlogback ولكن هذا هو بسبب وعدم التسبب البيانات أقوم بإجراء فوق :))

واعتقدت أن استخدام log4j - كما ذكر @ ScArcher2، فقط لأن الجميع يفعل. ولكن بعد التعامل مع كل الخيارات، اكتشفت java.util.logging هو أبعد ما يكون كافيا بما فيه الكفاية بالنسبة لمعظم احتياجاتي - وأنا أتحدث عن نظام ضخم مع العديد من المكونات انتشار تعمل معا

وهكذا، في رأيي، ليست هناك حاجة لاستخدام خدمات بديلة. Java.util.logging هي قوية بما يكفي لمعظم الحالات.

ونحن نستخدم log4j مع <لأ href = "http://commons.apache.org / تسجيل / "يختلط =" نوفولو noreferrer "> المشاعات في تسجيل . أعتقد أننا مجرد استخدامها ليفعل الجميع. ذلك وكنا باستخدام log4j قبل تسجيل جدك معتمد.

وتحرير: ولمجرد الجميع لا كان مزحة، ولكن ربما السبب في أنني بدأت مع log4j والمشاعات تسجيل

وهنا بعض الأسباب لاستخدام المشاعات تسجيل.

من السهل جدًا كتابة أ j.u.l LogManager فئة والتي ستؤجل جميع عمليات التسجيل إلى تطبيق مخصص يستخدم Log4J.هذا يعني أنه يمكنك استخدام log4j ولكن لا يزال لديك الميزة الرائعة المتمثلة في أنه يمكن التحكم في المكتبات التي تسجل باستخدام j.u.l كما لو كانت قد استخدمت Log4J.

بعد استخدام كليهما (والتسجيل المشترك)، يجب أن أقول إن الشيء الذي حقًا، حقًا, حقًا يزعجني هو هذا:

log4j.error("An Exception", e);

jul.severe("An Exception", e); // GRRR! no such method

jul.log(Level.SEVERE, "An Exception", e); //Must use this method

لماذا قاموا باختيار هذا التصميم؟لماذا؟والشيء الآخر هو أنه لا يوجد PatternFormatter الذي يشحن مع j.u.l - عليك أن لفة بنفسك.

ومع ذلك، أنا مخطئ في الاستخدام j.u.l من الآن فصاعدا لأنه يقلل من التبعيات الخارجية ولم يعد استخدامه أكثر تعقيدا.

في المشاريع التي أعمل عليها، فإننا نميل إلى استخدام المشاعات قطع الأشجار من جاكرتا. هذا ليس نظام تسجيل نفسه، بدلا من ذلك أنها قادرة على التفاف بعض الحطابين الأكثر شيوعا - log4j، java.util.logging أو غيرها.

مع ذلك، فمن الممكن بسهولة نسبيا لتبديل قطع الأشجار على أساس البيئة ونشر التطبيق إلى (مطور قد ترغب في استخدام simplelog أو java.util.logging على جهازه بسبب سهولة الصيانة، بينما كان في SIT النظام، قد يتم نشرها log4j مع تكوين مشترك لجميع التطبيقات وما إلى ذلك).

كل هذا يتوقف حقًا على متطلبات التسجيل الخاصة بك.لا تنظر إلى واجهة برمجة التطبيقات (API) التي يستخدمها مطورو التطبيقات فقط، وبصراحة، هذا هو أقل المشكلة حيث يسهل تكيف واجهات برمجة التطبيقات (APIs) للجزء الأكبر بغض النظر عن الاختيار الذي تقوم به.

الجزء المهم هو نوع تكوين التسجيل الذي تحتاجه عمليات وعليهم أن يخبروك بما يحتاجون إليه.

  1. يمكن أن يكون الأمر بسيطًا مثل الملفات النصية التي يتم تمريرها.
  2. يمكن أن يكون الأمر أكثر تعقيدًا مثل تسجيل الدخول إلى JMS أو قاعدة البيانات.
  3. وقد يتطلب الأمر سجلات منفصلة للأداء والتدقيق وما إلى ذلك.
  4. قد يتطلب إرسال تفاصيل بالبريد الإلكتروني عند حدوث حدث سجل.

حصل Log4J في حزمة varia الخاصة بهم على دعم لهذه العناصر والمزيد وتم اختبارها باستخدام واجهات برمجة التطبيقات الخاصة بهم.الآن باستخدام java.util.logging، من المفترض أن تكون قادرًا على تنزيلها، ولكنها ليست معرفة شائعة مثل Log4J وقد يكون من الصعب العثور على معلومات عنها.

شيء آخر يجب مراعاته هو واجهة برمجة تطبيقات البائع التي تستخدمها.يقوم معظم البائعين "بفرض" واجهة برمجة تطبيقات التسجيل نيابةً عنك.الربيع هو واحد منهم الذي يتطلب تسجيل المشاعات.

كمطور، سأحاول استخدام java.util.logging إذا استطعت لأشياءي الخاصة، ولكن في سيناريوهات العالم الحقيقي، عليك تغيير ما يحتاجون إليه في العمليات والسماح لذلك باختيارك لأنه هم هم الأشخاص الذين يتعين عليهم استخدام هذه السجلات عند تشغيل التطبيق.لا ينبغي لمهندس التطبيق ولا للمطورين اتخاذ هذا الاختيار، على الرغم من أنه ينبغي عليهم تقديم الاقتراحات.

شيء واحد لم يذكره أحد في هذا الموضوع - java.util.logging لا يدعم سجل النظام خارج الصندوق.يعد هذا بمثابة كسر للصفقة بالنسبة لي، (وقد سبب لي بعض الذعر من الاضطرار إلى إعادة هيكلة عناصر java.util.logging بدلاً من شيء يحتوي على المزيد من العصير.

إليك ما صادفته اليوم:

واحدة من المشاكل لدي مع ALL الأطر تسجيل هو أنه ما لم الجميع على فريقك ينفق من الوقت لإتقان في تمام كيفية إعداده والسيطرة عليه، لا يمكن معرفة ما إذا كان بيان التصحيح نظرا ستطبع خارجا أو لا .

قد يكون لديك مستوى (تصحيح) إيقاف، أو قد تكون لديكم تحولت حزمة واحدة خارج.

ولقد اهدر الكثير من الوقت على افتراض أن بيان التصحيح سوف طباعة ولا. الآن أنا أعتمد في الغالب على System.out.println () واذهبوا من خلال وحذف أو تحويلها عندما انتهيت التصحيح.

وأنا أعلم أن هذا لا يجيب على سؤالك - وأنا فقط أقول أنك قد ترغب في النظر في مدى مبرر لديك قبل أن يضيف التعقيد

وتسجيل ليست بهذا التعقيد وغير مبرر على معظم المشاريع الكبيرة بالتأكيد.

وأنا شخصيا استخدام المسجل بسيط ، ولكن في العمل I استخدام المجمع للشركات لدينا إلى مسجل JDK. يمكنني استخدام المسجل بسيط، نظرا لسهولة الحصول عليه إعداد وحقيقة أنه يدعم تسجيل من 7 مستويات بين قاتل وسخيف.

إذا كنت بحاجة إلى تسجيل الدخول إلى تطبيقك، فمن المحتمل أنك فعلت شيئًا خاطئًا حقًا.أود أن أزعم أن الإبلاغ عن المشكلة العرضية أمر جيد، ولكن وجود عبارات التصحيح والمعلومات وما إلى ذلك في الكثير من الفئات ذات المنطق أمر خاطئ تمامًا.أي تطبيق كبير يحتوي على عبارات تسجيل في معظم فئاته المملوءة بالمنطق سيؤدي إلى تحميل زائد للمعلومات حتى لو اختار الشخص المسجلين المناسبين فقط.في معظم الأحيان، ستكون المعلومات غير كاملة أو مزعجة أو أن المعلومات الفعلية التي تحتاجها مفقودة.

أنا أقول بشكل أساسي أنك يجب أن تحتاج فقط إلى كتابة عبارات تصحيح الأخطاء لإعلام المستخدم بتفاعلات البرنامج مع العوامل الخارجية

  • مشكلة التنسيق في ملف التكوين النصي.
  • مشاكل في فتح الملف المطلوب أو تحديد موقعه.
مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top