J2SE और J2EE अनुप्रयोगों को कॉन्फ़िगर करना: मानक तरीके और उनके विकल्प

आजकल, जावा अनुप्रयोगों के निर्माण के लिए कई विकल्प हैं और उनके विन्यास के कार्य विभिन्न तरीकों से हल किए जाते हैं।
आलेख मानक JDK टूल का उपयोग करके J2SE और J2EE अनुप्रयोगों को कॉन्फ़िगर करने की तकनीकों और सुविधाओं, साथ ही साथ इन विधियों के विकल्पों पर चर्चा करेगा।

J2SE

java.util.Properties

अनुप्रयोगों को कॉन्फ़िगर करने का क्लासिक तरीका java.util.Properties वर्ग का उपयोग करना है। अंदर सब कुछ बहुत सरल है - वास्तव में, यह java.util का एक विस्तार है। डिफ़ॉल्ट इंटरफ़ेस को सहेजने और डिफ़ॉल्ट मान को आरंभ करने की क्षमता वाला इंटरफ़ेस है।

इसके कई नुकसान हैं:

• कोई टाइपिंग - getProperty रिटर्न केवल स्ट्रिंग;
• कॉन्फ़िगरेशन फ़ाइल में परिवर्तनों को ट्रैक करना समर्थित नहीं है (यानी, जब घटनाओं को बदल दिया जाता है, तो कोई भी घटना उत्पन्न नहीं होगी और एप्लिकेशन को उनके बारे में कुछ भी नहीं पता होगा);
• केवल एक फ़ाइल के साथ काम करें। एन फाइलें = एन गुण के उदाहरण।

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

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

इस सब पर आपत्ति कर सकते हैं: "आप केवल सेटिंग फ़ाइल और ईवेंट जनरेशन सबसिस्टम का पुन: पठन जोड़ सकते हैं" - हाँ, यह सच है, केवल यह सब पहले से ही किया गया है और सबसे छोटा विवरण है जो अब अप्राप्य लगता है, लेकिन हमेशा आवश्यक रूप से स्वयं प्रकट होता है।
अगले लेख में मैं कॉमन्स कॉन्फ़िगरेशन के बारे में बात करूँगा और ऊपर उल्लिखित समस्याओं को कैसे हल किया जाए।
इस बीच, J2EE अनुप्रयोगों के लिए विशिष्ट कॉन्फ़िगरेशन विकल्पों पर विचार करें।

J2EE-EJB3

संसाधन इंजेक्शन

EJB अनुप्रयोगों को कॉन्फ़िगर करने के सबसे आसान तरीकों में से एक तैनाती डिस्क्रिप्टर (ejb-jar.xml) का उपयोग करना है:

< enterprise-beans >
< session >
< ejb-name > MyService </ ejb-name >
< env-entry >
< env-entry-name > myProperty </ env-entry-name >
< env-entry-type > java.lang.String </ env-entry-type >
< env-entry-value > 100500 </ env-entry-value >
</ env-entry >
</ session >
</ enterprise-beans >



डिस्क्रिप्टर में हम नाम (env-entry-name), प्रकार (env-entry-type) और पैरामीटर मान (env-entry-value) निर्दिष्ट करते हैं, जिसके बाद हम संसाधन एनोटेशन का उपयोग करके इसे इंजेक्ट करते हैं:

@Resource(name = "myProperty" )
private String myProperty;
@PostConstruct
public void postConstruct() {
System. out .println( "myProperty = " + myProperty);
}


यह दृष्टिकोण आपको निम्न प्रकार के मापदंडों के साथ काम करने की अनुमति देता है:

• java.lang.String
• java.lang.Boolean
• java.lang.Byte
• java.lang.Character
• java.lang.Double
• java.lang.Float
• java.lang.Integer
• java.lang.Long
• java.lang.Short

नुकसान में यह तथ्य शामिल है कि मापदंडों को बदलने से पुन: आवेदन होता है, जो बदले में, एक निश्चित अवधि की निष्क्रियता की ओर जाता है।
री-परिनियोजन नीति एप्लिकेशन सर्वर पर एप्लिकेशन डिस्क्रिप्टर चेंज स्कैनर की सेटिंग्स पर निर्भर करती है।
इसलिए, उदाहरण के लिए, JBoss 5.x-6.x एप्लिकेशन सर्वर के मामले में, ejb-jar.xml को बदलने से फिर से विफलता (जब तक, निश्चित रूप से, स्कैनर बंद कर दिया जाता है और JMX कंसोल के माध्यम से मैन्युअल रूप से पुन: परिनियोजन किया जाता है) के नेतृत्व की गारंटी है।

बाहरी सेटिंग फ़ाइल का उपयोग करना

एक बहुत उपयोगी दस्तावेज है - ईजेबी तकनीक की सीमाएं । इस दस्तावेज़ में फ़ाइल संसाधनों का उपयोग न करने के स्पष्ट संकेत हैं। संकेत इस प्रकार हैं:

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

हालाँकि, फ़ाइलों को केवल-पढ़ने के लिए डेटा स्रोतों के रूप में उपयोग करना स्वीकार्य है जब वे ईई अनुप्रयोगों के अंदर होते हैं। तथ्य यह है कि क्लस्टर तैनाती के मामले में, ईई आवेदन सभी नोड्स पर समान होगा।

इस प्रकार, हम EE अनुप्रयोगों के अंदर java.util.Properties के क्लासिक उपयोग के मामले में आते हैं:

@Stateless(mappedName = "BackendService" )
public class BackendServiceBean implements BackendServiceLocal {

private static final String P_PROPERTIES = "myProperties.properties" ;

private static final Logger logger = LoggerFactory.getLogger(BackendServiceBean. class );

@EJB
private DataRepositoryLocal dataRepository;

@Resource(name = "remoteURL" )
private String remoteURL;

private Properties properties;

@PostConstruct
private void init(){
InputStream propertiesResource = null ;
try {
propertiesResource = getClass().getResourceAsStream(P_PROPERTIES);
properties = new Properties();
properties.load(propertiesResource);
} catch (Exception e) {
logger.error( "Error" , e);
} finally {
if (propertiesResource != null ){
try {
propertiesResource.close();
} catch (Exception e) {
logger.error( "Error" , e);
}
}
}
}

public Properties getProperties() {
return properties;
}



नुकसान वही हैं जो पहले J2SE और java.util.Properties के लिए इंगित किए गए थे। इसके अलावा, हम J2EE के संदर्भ में हैं और यह केवल एक धारा नहीं जोड़ सकता है जो फ़ाइल परिवर्तनों पर नज़र रखता है और घटनाओं को उत्पन्न करता है (क्योंकि आप एक J2EE आवेदन में धाराएं नहीं बना सकते हैं)।
कोई यह कह सकता है: "आपको हमारे प्रॉपर्टी-प्रॉक्सी ऑब्जेक्ट पर एप्लिकेशन को getProperty कॉल करने पर हर बार .properties फ़ाइल पढ़ने की आवश्यकता है।" हां, आप ऐसा कर सकते हैं, लेकिन इस मामले में आपको आवेदन के उच्च प्रदर्शन के बारे में भूल जाना चाहिए - पढ़ने के लिए एक फ़ाइल खोलना, इसे बफर में लोड करना, पार्स करना और गुणों का एक उदाहरण बनाना प्रसंस्करण में ध्यान देने योग्य देरी का परिचय देगा।
इस समाधान का उपयोग करने का सही तरीका विशेष रूप से स्थिर रीड-ओनली सेटिंग्स को स्टोर करना है।

अन्य विकल्प

पहले वर्णित विकल्पों में एक खामी है - सही काम केवल स्थैतिक मापदंडों के साथ प्रदान किया जाता है। यदि आपको हमेशा एक पैरामीटर के वर्तमान मूल्य को प्राप्त करने की आवश्यकता होती है, तो आपको अन्य विकल्पों की तलाश करने की आवश्यकता है।

J2EE अनुप्रयोगों के लिए, ये विकल्प हो सकते हैं:

• डेटाबेस से सेटिंग्स प्राप्त करना (इसके अलावा, एक और एप्लिकेशन डेटाबेस में प्रवेश करने में लगा हुआ है - उदाहरण के लिए, व्यवस्थापक-कॉन्फ़िगरेशनकर्ता);
• दूरस्थ प्रदाता घटक से सेटिंग्स का अनुरोध करें (उदाहरण के लिए, कॉन्फ़िगरेशनप्रोवाइडर नाम)।

दोनों J2EE और J2SE अनुप्रयोगों के लिए, आप विभिन्न फ्रेमवर्क का उपयोग कर सकते हैं / अपना स्वयं का बना सकते हैं, जो कॉन्फ़िगरेशन की समस्याओं को हल करने के लिए अनुरूप हैं।

J2EE-सर्वलेट्स

सर्वलेट्स को कॉन्फ़िगर करते समय, हम web.xml डिस्क्रिप्टर के साथ काम कर रहे हैं, जिसमें हम उन मापदंडों को सेट करते हैं जिनकी हमें आवश्यकता है:

< web-app version ="2.5" xmlns ="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi ="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation ="http://java.sun.com/xml/ns/j2ee java.sun.com/xml/ns/j2ee/web-app_2_5.xsd" >

<!-- -->
< context-param >
< param-name > myContextParam1 </ param-name >
< param-value > value1 </ param-value >
</ context-param >
< context-param >
< param-name > myContextParam2 </ param-name >
< param-value > value2 </ param-value >
</ context-param >

<!-- -->
< filter >
< filter-name > myFilter </ filter-name >
< filter-class > net.universe.filter.EntityAccessFilter </ filter-class >
< init-param >
< param-name > checkType </ param-name >
< param-value > ldap </ param-value >
</ init-param >
< init-param >
< param-name > myParam </ param-name >
< param-value > true </ param-value >
</ init-param >
</ filter >

<!-- -->
< servlet >
< servlet-name > MyServlet </ servlet-name >
< servlet-class > net.universe.servlet.MyServlet </ servlet-class >
< init-param >
< param-name > servletParam1 </ param-name >
< param-value > paramValue1 </ param-value >
</ init-param >
< load-on-startup > 1 </ load-on-startup >
</ servlet >
</ web-app >


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

सभी के लिए सामान्य

System.getProperty

इन कॉन्फ़िगरेशन विधियों में से सभी के लिए सामान्य है जावा अनुप्रयोग लॉन्च लाइन में पारित सिस्टम मापदंडों का उपयोग:
java -DmyProperty1=myPropertyValue1 -DmyProperty2=myPropertyValue2 -jar myapp.jar


उसके बाद, java.lang.System वर्ग का उपयोग करके कॉन्फ़िगरेशन पैरामीटर लिया जा सकता है:
String string = System.getProperty("myProperty1");


यह विधि सीमित रूप से J2EE के साथ काम करने के संदर्भ में लागू है - जब क्लस्टर मोड में काम करते हैं, तो सिस्टम चर सभी नोड्स पर नहीं आ सकता है। क्यों "कर सकते हैं" - क्योंकि, उदाहरण के लिए, JBoss एप्लिकेशन सर्वर में SystemPropertiesService सेवा है और इसके कॉन्फ़िगरेशन के टुकड़े हमारे EE एप्लिकेशन में शामिल किए जा सकते हैं (अर्थात, "सिस्टम" चर सभी नोड्स पर होगा, क्योंकि यह होगा विन्यास फाइल में अनुप्रयोग के भाग के रूप में)।

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

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

JMX

JMX बहुत सारी चीजों के लिए एक सुविधाजनक उपकरण है, जिसमें अनुप्रयोगों को कॉन्फ़िगर करना भी शामिल है। आप java.util.Properties/Commons कॉन्फ़िगरेशन और उजागर MBean के उपयोग को हमारे मापदंडों के मूल्यों को स्थापित करने / प्राप्त करने के तरीकों के साथ जोड़ सकते हैं (स्थापना के दौरान, प्रतिनिधिमंडल द्वारा properties.setProperty के लिए)।
एक समान समाधान सफलतापूर्वक लागू किया जा सकता है जहां कॉन्फ़िगरेशन फ़ाइलों तक कोई पहुंच नहीं है, लेकिन नेटवर्क के माध्यम से MBeanServer तक पहुंच है।

इस दृष्टिकोण के नुकसान इस प्रकार हैं:

• J2SE अनुप्रयोगों में JMX सबसिस्टम डिफ़ॉल्ट रूप से बंद है;
• यह केवल साधारण प्रकार के मापदंडों का उपयोग करने की अनुमति है (जटिल वाले भी संभव हैं, लेकिन फिर जोकन्स के माध्यम से नियंत्रण काम नहीं करेगा);
• जे 2 ईई के संदर्भ में, जेएमएक्स के साथ काम करना बहुत जटिल रूप ले सकता है। इसलिए, उदाहरण के लिए, JBoss 4.x-6.x माइक्रोकर्नेल JMX को अपने आधार के रूप में उपयोग करता है और जोन्कोस ट्री को जोन्कोस उपयोगिता में प्राप्त करने का प्रयास होता है, उच्च स्तर की संभावना के साथ, इसके ठंड / धीमी गति से संचालन के लिए नेतृत्व करेगा।

अभी के लिए बस इतना ही।

निकट भविष्य में, कॉमन्स कॉन्फ़िगरेशन लाइब्रेरी पर एक लेख पूरा हो जाएगा, जो J2SE और J2EE अनुप्रयोगों में कॉन्फ़िगरेशन फ़ाइलों के साथ काम करने की संभावनाओं को बहुत विस्तार देता है।

आपका ध्यान के लिए धन्यवाद!