हम सर्वर पर एक अलग निर्देशिका में डालने के लिए क्या करते हैं (आप
कुछ/config,/opt/config,/root/config,/home/username/config, या जो
कुछ भी आप चाहते हैं) का उपयोग कर सकते हैं। जब हमारे servlets शुरू
होते हैं, वे एक्सएमएल फ़ाइल पढ़ते हैं, इसमें से कुछ चीजें प्राप्त
करें (सबसे महत्वपूर्ण रूप से डीबी कनेक्शन जानकारी), और यही वह
है।
मैंने पूछा कि हमने यह क्यों किया।
डीबी में सबकुछ स्टोर करना अच्छा लगेगा, लेकिन जाहिर है कि आप डीबी
में डीबी कनेक्शन की जानकारी स्टोर नहीं कर सकते हैं।
आप कोड में चीजें हार्डकोड कर सकते हैं, लेकिन यह कई कारणों से
बदसूरत है। अगर जानकारी को कभी भी बदलना है तो आपको कोड को फिर से
बनाना और पुनर्वितरण करना होगा। अगर किसी को आपके कोड या आपकी
डब्ल्यूएआर फ़ाइल की एक प्रति प्राप्त होती है तो उन्हें वह जानकारी
मिल जाएगी।
WAR फ़ाइल में चीजें डालना अच्छा लगता है, लेकिन यदि आप चीजों को
बदलना चाहते हैं तो यह एक बुरा विचार हो सकता है। समस्या यह है कि यदि
आपको जानकारी बदलनी है, तो अगली बार जब आप पुन: नियोजित करेंगे तो यह
फ़ाइल को ओवरराइट कर देगा, इसलिए WAR में बनाए गए संस्करण में बदलने
के लिए आपको याद नहीं आया है।
फाइल सिस्टम चीज पर एक विशेष स्थान पर फ़ाइल हमारे लिए काफी अच्छी
तरह से काम करती है। इसमें कोई बड़ी डाउनसाइड्स नहीं है। आप जानते हैं
कि यह कहां है, यह अलग-अलग संग्रहीत है, कई मशीनों को तैनात करने में
आसान बनाता है अगर उन्हें सभी को अलग-अलग कॉन्फ़िगरेशन मानों की
आवश्यकता होती है (क्योंकि यह WAR का हिस्सा नहीं है)।
एकमात्र अन्य समाधान जो मैं सोच सकता हूं कि अच्छी तरह से काम
करेगा डीबी लॉगिन जानकारी को छोड़कर डीबी में सब कुछ रखेगा। यह जावा
सिस्टम गुणों से आएगा जो JVM के माध्यम से पुनर्प्राप्त किए जाते हैं।
यह प्राथमिकता एपीआई चीज ऊपर हंस डॉगजेन द्वारा उल्लिखित है। मुझे
नहीं लगता कि यह तब था जब हमारे आवेदन को पहले विकसित किया गया था,
अगर इसका इस्तेमाल नहीं किया गया था।
कॉन्फ़िगरेशन फ़ाइल तक पहुंचने के लिए पथ के लिए, यह फाइल सिस्टम
पर सिर्फ एक फ़ाइल है। आपको वेब पथ के बारे में चिंता करने की
आवश्यकता नहीं है। तो जब आपका सर्वलेट शुरू होता है तो यह फ़ाइल को
"/config/myapp/config.xml" (या जो कुछ भी) पर खुलता है और यह सही
चीज़ मिल जाएगा। इस के लिए पथ को बस हार्डकोड करना मेरे लिए बहुत
हानिकारक लगता है।