जावा वेबपैस में एम्बेडेड कॉन्फ़िगरेशन फ़ाइलों और पुस्तकालयों का प्रबंधन कैसे करते हैं?

Question

मैं वर्तमान में एक j2ee प्रोजेक्ट पर काम कर रहा हूं जो बीटा में थोड़ी देर के लिए रहा है। अभी हम तैनाती प्रक्रिया के साथ कुछ मुद्दों को हल कर रहे हैं। विशेष रूप से, युद्ध में एम्बेडेड कई फाइलें हैं (कुछ xml-files और .properties) जिन्हें आप देव, परीक्षण या उत्पादन वातावरण में हैं या नहीं, इस पर निर्भर करते हुए विभिन्न संस्करणों की तैनाती की आवश्यकता है। Loglevels, कनेक्शन पूल, आदि जैसे सामान

तो मैं सोच रहा था कि डेवलपर्स वेबपैप्स को तैनात करने के लिए अपनी प्रक्रिया कैसे बनाते हैं। क्या आप एप्लिकेशन सर्वर पर जितना कॉन्फ़िगरेशन कर सकते हैं उतना ही ऑफ़लोड कर सकते हैं? क्या आप तैनाती से पहले सेटिंग्स फ़ाइलों को प्रोग्रामेटिक रूप से प्रतिस्थापित करते हैं? निर्माण प्रक्रिया के दौरान एक संस्करण उठाओ? युद्धों को मैन्युअल रूप से संपादित करें?

इसके अलावा आप एप्लिकेशन सर्वर के स्थिर पुस्तकालयों के माध्यम से निर्भरता प्रदान करने में कितना दूर जाते हैं और आप युद्ध में कितना डालते हैं? यह सब कुछ इस विचार के बारे में कुछ विचार पाने के लिए है कि इस समय आम (या शायद सर्वश्रेष्ठ) अभ्यास क्या है।

Answer 1

मैं ऐसा माहौल एक अलग सर्वर टीम हमारे अनुप्रयोगों के लिए गुणवत्ता आश्वासन और उत्पादन सर्वर के विन्यास प्रदर्शन में काम करते हैं। प्रत्येक आवेदन आम तौर पर क्यूए में दो सर्वरों और उत्पादन में तीन सर्वरों पर तैनात किया जाता है। मेरे देव टीम की खोज की है कि यह सबसे अच्छा है युद्ध (या कान) में जितना संभव हो उतना विन्यास डालकर सर्वर पर आवश्यक विन्यास की मात्रा को कम करने के लिए। यह सर्वर कॉन्फ़िगरेशन को आसान बनाता है और यह भी कम करता है कि सर्वर टीम गलत तरीके से सर्वर को कॉन्फ़िगर करेगी।

हम मशीन विशिष्ट विन्यास की आवश्यकता नहीं है, लेकिन हम वातावरण-विशिष्ट विन्यास (देव, गुणवत्ता आश्वासन, और उत्पादन) की क्या ज़रूरत है। हम चाहते हैं कि पर्यावरण (उदा। Dev.properties, qa.properties, prod.properties) द्वारा नाम हैं युद्ध फ़ाइल में संग्रहीत विन्यास फाइल की है। हम (... उदा। जावा -Dapp.env = prod) पर्यावरण निर्दिष्ट करने के लिए सर्वर वी एम के जावा कमांड लाइन पर एक-डी संपत्ति डाल दिया। एप्लिकेशन app.env सिस्टम प्रॉपर्टी की तलाश कर सकता है और उपयोग करने के लिए प्रॉपर्टी फाइल का नाम निर्धारित करने के लिए इसका इस्तेमाल कर सकता है।

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

हम सर्वर पर कनेक्शन पूल कॉन्फ़िगर करें। हम कनेक्शन वातावरण को प्रत्येक पर्यावरण के लिए समान नाम देते हैं और बस उन सर्वरों को इंगित करते हैं जो उचित वातावरण में प्रत्येक वातावरण को आवंटित किए जाते हैं। एप्लिकेशन को केवल एक कनेक्शन पूल नाम पता होना है।

Answer 2

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

मुझे क्या करना है गुणों के साथ एक प्रोजेक्ट बनाना है। उदाहरण फ़ाइल, प्रत्येक मशीन में एक .properties है जो कहीं भी युद्ध कर सकती है।

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

Answer 3

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

Answer 4

मैं आमतौर पर दो गुण फ़ाइलें बनाना:

• एप्लिकेशन बारीकियों (संदेश, आंतरिक "जादू" शब्द) अनुप्रयोग में एम्बेडेड के लिए एक,
• पर्यावरण विशेष जानकारी के लिए अन्य (db का उपयोग, लॉग ऑन स्तरों & पथ ...) प्रत्येक सर्वर के क्लासपाथ पर खुलासा हुआ और "चिपकाया" (मेरे ऐप के साथ वितरित नहीं किया गया)। आम तौर पर मैं लक्ष्य env के आधार पर, विशिष्ट मूल्यों को रखने के लिए इन "mavenise" या "anttise"।
• कूल लोग अपने ऐप को बनाए रखने के लिए जेएमएक्स का उपयोग करते हैं (conf को रीयलटाइम में रीडाइम के बिना संशोधित किया जा सकता है), लेकिन यह मेरी ज़रूरतों के लिए बहुत जटिल है।

सर्वर (स्थिर?) पुस्तकालयों: मैं दृढ़ता से मेरी क्षुधा में सर्वर पुस्तकालय उपयोग को हतोत्साहित के रूप में यह सर्वर से निर्भरता को जोड़ता है:

1. IMO, मेरे ऐप होना चाहिए "आत्म पैक": छोड़ने मेरी युद्ध, और यह सब कुछ है। मैंने इसमें 20 एमबीएस जार के साथ युद्ध देखा है, और यह मेरे लिए परेशान नहीं है।J2EE एपीआई (सर्वलेट, EJBs, JNDI, JMX, JMS ... के उपयोग):
2. एक आम सबसे अच्छा अभ्यास क्या J2EE हठधर्मिता द्वारा की पेशकश की है करने के लिए अपने बाहरी निर्भरता को सीमित करने के लिए है। आपका ऐप "सर्वर अज्ञेयवादी" होना चाहिए।
3. आपके ऐप्लिकेशन (युद्ध, कान, wathever) में निर्भरता लाना स्वयं कुछ दस्तावेज़ीकृत है: आप जानते हैं कि लाइब्रेरी को अपने एप्लिकेशन पर निर्भर करता है। सर्वर libs के साथ, आपको इन निर्भरताओं को स्पष्ट रूप से दस्तावेज करना होगा क्योंकि वे कम स्पष्ट हैं (और जल्द ही आपके डेवलपर इस छोटे जादू को भूल जाएंगे)।
4. आप अपने appserver उन्नयन, तो संभावना सर्वर आप lib पर निर्भर करता है कि यह भी बदल जाएगा। ऐपसेवर संपादकों को अपने आंतरिक libs पर संस्करण से संस्करण (और अधिकांश समय, वे नहीं) पर संगतता बनाए रखने के लिए नहीं माना जाता है।
5. आप एक व्यापक रूप से इस्तेमाल lib अपने appServer में एम्बेडेड का उपयोग करें (जकार्ता कॉमन्स प्रवेश, JCL उर्फ, मन में आता है) और यह नवीनतम सुविधाएं प्राप्त करने के लिए संस्करण है ugrade करना चाहते हैं, तो आप बहुत बड़ा जोखिम ले कि आपके appServer का समर्थन नहीं करेंगे यह।
6. आप एक स्थिर सर्वर वस्तु पर निर्भर करता है, तो (एक सर्वर वर्ग के एक स्थिर क्षेत्र में, उदाहरण के लिए एक नक्शा या एक लॉग), आप अपने appserver इस वस्तु को साफ करने के रिबूट करना होगा। आप अपने ऐप को फिर से तैनात करने की क्षमता खो देते हैं (पुराने सर्वर ऑब्जेक्ट अभी भी पुनर्निर्माण के बीच मौजूद होगा)। ऐपसेवर-वाइड ऑब्जेक्ट्स का उपयोग करना (जे 2 ईई द्वारा परिभाषित किए गए अलावा) सूक्ष्म बग का कारण बन सकता है, खासकर यदि यह ऑब्जेक्ट एकाधिक ऐप्स के बीच साझा किया जाता है। यही कारण है कि मैं उन वस्तुओं के उपयोग को दृढ़ता से हतोत्साहित करता हूं जो ऐपसेवर lib के स्थिर क्षेत्र में रहते हैं।

आप पूरी तरह की जरूरत है "इस appserver के जार में इस वस्तु", उम्मीद है कि अन्य सर्वर के जार पर कोई निर्भरता है, और यदि आपके ऐप की classloading नीति की जाँच में अपने ऐप्लिकेशन में जार नकल करने की कोशिश (मैं आदत ले डाल करने के लिए एक "माता-पिता पिछले" मेरे सभी क्षुधा पर नीति classloading: मुझे यकीन है कि मैं सर्वर के जार द्वारा "प्रदूषित" नहीं होगा हूँ - लेकिन अगर यह एक "सबसे अच्छा अभ्यास") है मैं नहीं जानता।

Answer 5

wrt विन्यास फाइल, मुझे लगता है कि Steve's जवाब सबसे अच्छा एक अब तक है। मैं युद्ध फाइल के इंस्टॉलेशन पथ से संबंधित बाहरी फाइलों को बनाने का सुझाव जोड़ूंगा - इस तरह आप एक सर्वर में विभिन्न विन्यासों के साथ युद्ध के कई इंस्टॉलेशन कर सकते हैं।

उदामेरी dev.war/opt/tomcat/webapps/dev में अनपैक किया जाता है, तो मैं ServletContext.getRealPath का उपयोग आधार फ़ोल्डर और युद्ध फ़ोल्डर नाम को खोजने के लिए होगा, इसलिए तो विन्यास फाइल निरपेक्ष के लिए /opt/tomcat/config/dev../../config/dev युद्ध के सापेक्ष, या में रहते हैं।

मैं इन बाहरी विन्यास फाइलों में जितना संभव हो उतना छोटा डालने के बारे में Bill से भी सहमत हूं। जितना ज्यादा समझ में आता है उतना स्टोर करने के लिए अपने पर्यावरण के आधार पर डेटाबेस या जेएमएक्स का उपयोग करना। अपाचे कॉमन्स कॉन्फ़िगरेशन में डेटाबेस तालिका द्वारा समर्थित कॉन्फ़िगरेशन को संभालने के लिए nice object है।

पुस्तकालयों के संबंध में, मैं unknown से सहमत हूं कि युद्ध फ़ाइल (स्वयं पैक) में WEB-INF/lib फ़ोल्डर में सभी libs हैं। लाभ यह है कि आवेदन की प्रत्येक स्थापना स्वायत्त है, और आपके पास पुस्तकालयों के विभिन्न संस्करणों का उपयोग करके युद्ध के अलग-अलग निर्माण हो सकते हैं।

नुकसान यह है कि यह अधिक स्मृति का उपयोग करेगा क्योंकि प्रत्येक वेब एप्लिकेशन में कक्षाओं की अपनी प्रतिलिपि होगी, जो अपने स्वयं के वर्ग लोडर द्वारा लोड की जाएगी।

यदि यह वास्तविक चिंता उत्पन्न करता है, तो आप अपने सर्वलेट कंटेनर ($CATALINA_HOME/lib टॉमकैट के लिए) के लिए सामान्य लाइब्रेरी फ़ोल्डर में जार डाल सकते हैं। उसी सर्वर पर चल रहे आपके वेब एप्लिकेशन की सभी इंस्टॉलेशन को पुस्तकालयों के समान संस्करणों का उपयोग करना पड़ता है। (असल में, यह सख्ती से सच नहीं है क्योंकि आप आवश्यक होने पर व्यक्तिगत WEB-INF/lib फ़ोल्डर में ओवरराइडिंग संस्करण डाल सकते हैं, लेकिन इसे बनाए रखने के लिए बहुत गन्दा हो रहा है।)

मैं इस मामले में सामान्य पुस्तकालयों के लिए एक स्वचालित इंस्टॉलर का निर्माण करूंगा, इंस्टॉलशल्ड का उपयोग कर या NSIS या अपने ऑपरेटिंग सिस्टम के बराबर। ऐसा कुछ जो आपको यह बता सकता है कि क्या आपके पास पुस्तकालयों का सबसे अद्यतित सेट है, और अपग्रेड, डाउनग्रेड इत्यादि।