क्या यह अतिरिक्त परत में लॉगिंग फ्रेमवर्क को लपेटने लायक है?

Question

मैं वर्तमान में एक मध्यम से बड़े आकार के जावा कोडबेस में लॉगिंग तंत्र को अपग्रेड करने की तलाश में हूं। संदेश वर्तमान में Debug कक्षा पर स्थिर विधियों का उपयोग करके लॉग इन किए गए हैं, और मैंने एसएलएफ 4 जे या कॉमन्स-लॉगिंग जैसे कुछ से स्विच करने की अनुशंसा की है।

एप्लिकेशन आर्किटेक्ट पसंद करता है कि मैं एसएलएफ 4 जे पर निर्भरता को समाहित करता हूं (संभवतः उपर्युक्त Debug कक्षा में इसे लपेटकर)। इससे भविष्य में लॉगिंग कार्यान्वयन को बदलना आसान हो जाएगा।

यह मेरे लिए अधिक पसंद है, क्योंकि एसएलएफ 4 जे पहले ही कंक्रीट लॉगिंग कार्यान्वयन को सार कर रहा है।

क्या में एसएलएफ 4 जे जैसे किसी तीसरे पक्ष के लॉगिंग अबास्ट्रक्शन को लपेटना उचित है घर से उगाए जाने वाले अमूर्तता?

Answer 1

मैं पूरी तरह से आपसे सहमत हूं: रैपर के रैपर के रैपर हाथ से बाहर हो रहे हैं। मुझे संदेह है कि आर्किटेक्ट को यह नहीं पता कि एसएलएफ 4 जे विशेष रूप से किसी अन्य लॉगिंग सिस्टम को कैसे लपेट सकता है, ताकि "कार्यान्वयन बदलना" पूरी तरह से लपेटने के बिना किसी अन्य परत के हो।

Answer 2

यदि आप भविष्य में लॉगिंग फ्रेमवर्क स्विच करने की सोच रहे हैं, तो आप लॉगर को स्विच करने के लिए अतिरिक्त परत जोड़ने के लिए उपयुक्त हो सकते हैं। अन्यथा, अगर वे आपको जो कुछ भी संभवतः प्रदान करेंगे, वह आपको प्रदान करेगा (निश्चित रूप से आपकी क्रिस्टल बॉल का उपयोग करके) तो संभव है कि उस ढांचे पर हार्ड निर्भरता हो।

यदि आपका वर्तमान सेटअप लचीलापन बदलने की अनुमति देता है, तो आपको एक रैपर की आवश्यकता नहीं है।

Answer 3

अपने Architecture Astronaut को समझाएं कि slf4j पहले से ही log4j जैसे अन्य लॉगिंग कार्यान्वयन के लिए एक रैपर के रूप में कार्य कर सकता है। इसलिए यदि आपको भविष्य में कुछ अन्य लॉगर का उपयोग करने की आवश्यकता है और slf4j के लिए कोई एडाप्टर नहीं है, तो आवश्यकता होने पर आप इसे लिख सकते हैं, लेकिन यह एक संपूर्ण लॉगिंग फ्रेमवर्क लिखने के बजाय एडाप्टर होगा, जो बस कुछ अन्य लपेटेगा लॉगिंग फ्रेमवर्क और आपको इसके लिए अपना ढांचा तैयार करने और अपना एडाप्टर लिखने की आवश्यकता है।

Answer 4

मैं इसे लपेटना पसंद करूंगा, लेकिन निर्दिष्ट कारण के लिए नहीं। यदि चिंता किसी अन्य ढांचे के लिए स्वैप करने की क्षमता है, तो java.util.logging या SLF का उपयोग करें (java.util.logging एक रैपर के रूप में उपयोग करने में आसान नहीं है, लेकिन यह काफी काम करने योग्य है), और स्वैप करें। उपयोग करने का कारण (अभी तक एक और) रैपर कोड में कोडिंग को उचित तरीके से कोडित करना है। आम तौर पर एक एप्लिकेशन एक सबसेट चाहता है, जैसे सभी सिस्टम त्रुटियां अपवाद के साथ आती हैं, या मानक लॉगिंग स्तरों का उपयोग करने के बारे में विशिष्ट मार्गदर्शन है। उन निर्णयों को एक बड़े कोड बेस पर अधिक लगातार लॉगिंग निर्णय लेने के कुछ तरीकों से encapsulated किया जा सकता है।

हालांकि, प्रेरणा केवल कार्यान्वयन को स्वैप करना संभव बनाने के लिए है, पहिया को पुन: पेश न करें। एसएलएफ नौकरी के लिए बिल्कुल सही है, बस इसका इस्तेमाल करें।

इसमें एक अपवाद है। यदि आपका कोड असंख्य रूप से कई संभावित ऐप सर्वरों में तैनात किया गया है, तो आपको यह सुनिश्चित करना होगा कि आपकी लॉगिंग पसंद फ्रेमवर्क का उपयोग करने वाले संभावित पुराने या नए संस्करणों के साथ संघर्ष करने का जोखिम नहीं उठाती है।

Answer 5

हर आवरण के साथ समस्या यह

कैसे आप वास्तव में लपेट कर देंगे और आपको प्रदान करेंगे जो कार्यक्षमता का फैसला है:

• commons.logging, लॉगिंग कार्यक्षमता का एक न्यूनतम सेट प्रदान कर रहा है अतिरिक्त कार्यक्षमता दूर छिपा है कि अंतर्निहित ढांचा प्रदान कर सकता है। आपको पैरामीटरयुक्त लॉगिंग या एमडीसी जैसी उन्नत सुविधाएं नहीं मिलेंगी।
• SLF4J आसपास के दूसरे तरीके से काम करता है। यह उन बुनियादी ढांचे के शीर्ष पर लागू करके पैरामीटरयुक्त लॉगिंग जैसी उन्नत सुविधाओं को संभालता है जो उन्हें मूल रूप से कार्यान्वित नहीं कर रहे हैं। यह बेहतर तरीका है, आईएमएचओ।

मुझे आपकी वर्तमान डीबग कक्षा नहीं पता लेकिन मुझे लगता है कि यह काफी बुनियादी है।

अलग प्रवेश के स्तर की तरह

• लॉगिंग संदेश के स्थान, स्रोत फ़ाइल + लाइन नंबर की यानी नाम

  आप शायद नहीं होगा सुविधाओं

• क्षमता चुनिंदा स्तर सेट करने के विभिन्न लॉगर्स के, यानी आपके पास प्रति वर्ग एक लॉगर नहीं है, जिसमें उस लॉगर को ब्याज के एक निश्चित स्तर पर सेट करने की क्षमता है, उदाहरण के लिए जानकारी, चेतावनी। यह बहुत महत्वपूर्ण है।

यदि आपका डीबग वर्ग सुंदर बुनियादी यह वास्तव में आप के लिए बहुत अच्छा है :) है

इसका मतलब है कि आप की संभावना एक वैश्विक खोज & Destr प्रदर्शन से SLF4J पर स्विच कर सकते हैं। .. गलती ... प्रतिस्थापित करें।

, बैकअप बनाने हालांकि ...;)

भी Should new projects use logback instead of log4j?, What’s Up with Logging in Java?, Which log4j facade to choose?, Find a way in the java logging frameworks scene. और Do you find java.util.logging sufficient? देखें। (स्पोइलर: आपको java.util.logging का उपयोग नहीं करना चाहिए, कृपया 0)

Answer 6

मुझे लगता है कि रैपर को लपेटने के आर्किटेक्ट की इच्छा के पीछे प्रेरणा (यानी एसएलएफ 4 जे), एसएलएफ 4 जे से आपके आवेदन को अलग करना है। जाहिर है, आपके आवेदन के भीतर से SLF4J एपीआई का आह्वान एसएलएफ 4 जे पर निर्भरता बनाता है। हालांकि, नीचे चर्चा के अनुसार बार-बार अलगाव सिद्धांत को लागू करना चाहते हैं। यह मुझे रिचर्ड डॉकिन्स के प्रश्न की याद दिलाता है: अगर भगवान ने ब्रह्मांड बनाया, तो भगवान ने किसने बनाया?

वास्तव में, आप SLF4J को लपेटने वाले रैपर पर अलगाव सिद्धांत भी लागू कर सकते हैं। एसएलएफ 4 जे-रैपर किसी भी तरह एसएलएफ 4 जे से कम था, तो अलगाव का कारण बीमार होगा। यद्यपि संभव है, एक रैपर के बराबर या मूल को पार करने के लिए यह दुर्लभ है। एसडब्ल्यूटी को एक उल्लेखनीय काउंटर उदाहरण के रूप में उद्धृत किया जा सकता है। हालांकि, एसडब्ल्यूटी एक महत्वपूर्ण लागत के साथ एक बड़ी परियोजना है। इस बिंदु पर, परिभाषा के अनुसार एक एसएलएफ 4 जे-रैपर एसएलएफ 4 जे पर निर्भर करता है। यह एक ही सामान्य एपीआई होना बाध्य है। यदि भविष्य में एक नया और महत्वपूर्ण रूप से अलग लॉगिंग एपीआई आती है, तो रैपर का उपयोग करने वाले कोड को नए एपीआई में सीधे एसएलएफ 4 जे का उपयोग करने वाले कोड के रूप में माइग्रेट करना मुश्किल होगा। इस प्रकार, रैपर भविष्य में आपके कोड को प्रमाणित करने की संभावना नहीं है, लेकिन अतिरिक्त संकेत जोड़ने के द्वारा इसे भारी बनाने के लिए।

संक्षेप में, भले ही आपके पास कुछ भी बेहतर न हो, आपको अपने समय को एसएलएफ 4 जे लपेटना नहीं चाहिए क्योंकि आपके रैपर का जोड़ा मूल्य शून्य के करीब होने की गारंटी है।

विषय को SLF4J FAQ entry में भी ब्रोच किया गया है।