2010-04-26 15 views
23

मैं एक साधारण परीक्षण ऐप में log4j को आजमा रहा हूं। मैं ग्रहण में एक नई जावा प्रोजेक्ट बनाता हूं और अपने बिल्ड पथ में log4j JAR (v1.2.16) जोड़ता हूं। मैं फिर एक साधारण वर्ग बनाता हूं जो हैलो वर्ल्ड प्रिंट करता है। फिर मैं एक सूचना संदेश लॉग करने के लिए log4j Logger कक्षा का उपयोग करता हूं। जब मैं ऐप चलाता हूं, तो मुझे लॉग संदेश दिखाई देता है, जो मैं मानता हूं वह डिफ़ॉल्ट एपेंडर और लेआउट है। महान। मुझे अपनी समस्या का सामना करना पड़ रहा है। मैंने यह किया है:log4j log4j.properties फ़ाइल कहां/कैसे करता है?

एक कस्टम appender और लॉग स्तर के साथ log4j.properties फ़ाइल बनाई और उसे src फ़ोल्डर में रखा गया (जो संकलन पर बिन फ़ोल्डर में कॉपी हो जाता है)। ऐप चलाएं - कोई बदलाव नहीं।

मैं PropertyConfigurator.configure("log4j.properties") जोड़ने का प्रयास करता हूं। ऐप चलाएं - कोई बदलाव नहीं। कोई त्रुटि नहीं, लेकिन कोई बदलाव नहीं।

मेरी कॉन्फ़िगरेशन फ़ाइल लोड करने के लिए log4j प्राप्त करने के लिए मुझे क्या करना है?

उत्तर

7

अरघ। मुझे पता चला कि समस्या यह थी कि ग्रहण ने गलत Logger कक्षा आयात की थी। उसने java.util.logging आयात किया था। लॉगर जिसकी निश्चित रूप से यह स्वयं की कॉन्फ़िगरेशन है जो log4j से अलग है। ओह ठीक है, उम्मीद है कि कोई और ऐसा करता है और इस प्रश्न को पढ़कर हल हो जाता है।

+0

हेक्टेयर, खराब आयात जो संकलन समय पर नहीं पाए जाते हैं वे दर्द होते हैं ... :-) – leonbloy

+0

मैं हर समय ऐसा करता हूं। – justkt

7

आप log4j.debug सिस्टम प्रॉपर्टी सेट करके लॉग 4j आंतरिक डिबगिंग सक्षम कर सकते हैं। अन्य चीजों के अलावा, यह log4j को दिखाएगा कि यह स्वयं को कैसे कॉन्फ़िगर कर रहा है।

आप log4j.configuration सिस्टम प्रॉपर्टी के साथ कॉन्फ़िगरेशन फ़ाइल में URL को स्पष्ट रूप से सेट करने का प्रयास कर सकते हैं।

यह भी देखें: this question

2

log4j.properties आपके क्लासपाथ में होना चाहिए। "Src फ़ोल्डर" जिसे "बिन फ़ोल्डर" में कॉपी किया गया है (मुझे लगता है कि आप यहां ग्रहण सेटअप के बारे में बात कर रहे हैं), आमतौर पर आपके क्लासपाथ से संबंधित होता है, इसलिए यह पाया जाना चाहिए (क्या आप इसे "स्रोत के शीर्ष पर रखते हैं "फ़ोल्डर, सही?)

34

उन है कि RTFM नहीं किया है, शीर्षक Default Initialization Procedure, जहाँ आप मिल जाएगा के तहत देखें लिए निम्नलिखित:

सटीक डिफ़ॉल्ट प्रारंभ एल्गोरिथ्म इस प्रकार परिभाषित किया गया है:

  1. स्थापना log4j.defaultInitOverride "false" से किसी भी अन्य मूल्य के लिए सिस्टम प्रॉपर्टी लॉग 0j को डिफ़ॉल्ट प्रारंभिक प्रक्रिया (इस प्रक्रिया) को छोड़ने का कारण बन जाएगी।
  2. संसाधन स्ट्रिंग वैरिएबल को log4j.configuration सिस्टम प्रॉपर्टी के मान पर सेट करें। निर्दिष्ट करने का पसंदीदा तरीका log4j.configuration सिस्टम प्रॉपर्टी के माध्यम से डिफ़ॉल्ट प्रारंभिक फ़ाइल है। यदि सिस्टम प्रॉपर्टी log4j.configuration परिभाषित नहीं है, तो स्ट्रिंग वेरिएबल संसाधन को डिफ़ॉल्ट मान "log4j.properties" पर सेट करें।
  3. संसाधन चर को एक यूआरएल में परिवर्तित करने का प्रयास करें।
  4. संसाधन चर उदाहरण के लिए एक MalformedURLException के कारण, एक यूआरएल में परिवर्तित नहीं किया जा सकता है, तो बुला org.apache.log4j.helpers.Loader.getResource (संसाधन, Logger.class द्वारा classpath से संसाधन के लिए खोज) जो एक यूआरएल देता है।ध्यान दें कि स्ट्रिंग "log4j.properties" एक विकृत यूआरएल का गठन करता है। खोजे गए स्थानों की सूची के लिए Loader.getResource(java.lang.String) देखें।
  5. यदि कोई यूआरएल नहीं मिला, तो डिफ़ॉल्ट प्रारंभिकरण रद्द करें। अन्यथा, यूआरएल से log4j कॉन्फ़िगर करें। PropertyConfigurator log4j कॉन्फ़िगर करने के लिए जब तक यूआरएल समाप्त होता है ".xml" विस्तार, जिस स्थिति में DOMConfigurator उपयोग किया जाएगा के साथ यूआरएल पार्स करने के लिए इस्तेमाल किया जाएगा। आप वैकल्पिक रूप से एक कस्टम विन्यासकर्ता निर्दिष्ट कर सकते हैं। log4j.configuratorClass सिस्टम प्रॉपर्टी का मान आपके कस्टम कॉन्फ़िगरेटर के पूर्ण योग्य क्लास नाम के रूप में लिया जाता है। आपके द्वारा निर्दिष्ट कस्टम कॉन्फ़िगरेटर को Configurator इंटरफ़ेस को लागू करना होगा।
+0

कभी-कभी आपको केवल आरटीएफएम होना चाहिए। थोड़ा जटिल होने पर, यह जानकारी आधिकारिक और बहुत स्पष्ट है और मुझे समस्या हल करने में मदद मिली है। +1! –

+6

एफएम कुछ पुराना है। 1.2.17 में 'LogManager.java' के स्रोत को देखते हुए, डिफ़ॉल्ट रूप से यह 'log4j.xml' (उस दस्तावेज़ में उल्लिखित नहीं) की तलाश करता है, इससे पहले कि यह' log4j.properties' 'दिखता है, और गुण फ़ाइल को निरंतर परिभाषित करना है घोषित '@ बहिष्कृत' (हालांकि यह केवल स्थिर के बाहरी उपयोग को रोकने के लिए लगता है)। – bacar

1

मैं जानता हूँ कि इस वर्ष दो महीने है, लेकिन मैं कहना है कि scr फ़ोल्डर बिन फ़ोल्डर में "की नकल की" नहीं है की जरूरत महसूस, न ही यह अपने क्रम classpath का हिस्सा है। ... (बिल्ड पथ रनटाइम क्लासपाथ नहीं है!)। ग्रहण स्रोत फ़ोल्डर में स्रोत फ़ाइलों को बिन (या जो भी आपको पसंद है) फ़ोल्डर में संकलित करता है। यह बिन फ़ोल्डर है जो आपके रनटाइम क्लासपाथ का हिस्सा है।

बस इसे इंगित करना चाहता था क्योंकि इन धागे को अक्सर जूनियर प्रोग्रामर द्वारा पढ़ा जाता है, और मैं हमेशा निराश हूं कि उनमें से अधिकतर जावा क्लासपाथ की कल्पना को समझ नहीं पाते हैं, और इसलिए इसके खिलाफ टालने योग्य गलतियां करते हैं यह।

4

समस्या classpath में हो सकती है, यदि classpath परिभाषित किया गया था।

कारण यह लोड नहीं हो रहा था (मेरे मामले में): मेरे जार में से एक में एक विरोधाभासी log4j.properties फ़ाइल थी, और यह मेरे classpath में से एक को ओवरलोड कर रहा था।

संक्षेप में, यदि आपकी log4j.properties फ़ाइल लोड नहीं हो रही है, तो कहीं और इसे ओवरराइड करने वाला कोई और हो सकता है।

बस सोचा कि मैं इसे भी फेंक दूंगा, अगर कोई और इसमें चलता है। मैंने पिछले 5 घंटों में यह पता लगाने की कोशिश की कि मेरा डिफ़ॉल्ट log4j.properties क्यों लोड नहीं होगा।

संबंधित मुद्दे