तीसरे पक्ष के अनुप्रयोग संदर्भ से स्प्रिंग बीन को सही ढंग से प्राप्त करना

शुभ दोपहर, Khabrovites!

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

समस्या कथन

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

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

वर्तमान में बाहरी अनुप्रयोग संदर्भ से बीन का उपयोग करने का एक उदाहरण

कल्पना करें कि हम एप्लिकेशन मॉड्यूल में से एक में विकसित कर रहे हैं, जिसमें कई अन्य मॉड्यूल हैं, और यह कि प्रत्येक मॉड्यूल का अपना एप्लिकेशन संदर्भ है। इस तरह के एप्लिकेशन में एक मॉड्यूल होना चाहिए जिसमें सभी एप्लिकेशन मॉड्यूल के एप्लिकेशन संदर्भ के उदाहरण बनाए जाते हैं।



मान लीजिए, बाहरी मॉड्यूल में से एक के अनुप्रयोग संदर्भ में, नंबरगर्नेटर क्लास के सेम का एक उदाहरण बनाया जाता है, जिसे हम अपने मॉड्यूल में प्राप्त करना चाहते हैं। यह भी मान लें कि NumberGenerator वर्ग पैकेज में स्थित है। org.example.kruchon.generators, जो मान उत्पन्न करने वाली कुछ कक्षाओं को संग्रहीत करता है।



इस बीन में एक राज्य है - इंट काउंट फ़ील्ड।

package org.example.kruchon.calculators public class NumberGenerator { private int count = 0; public synchronized int next() { return count++; } } 

इस बीन का एक उदाहरण जेनरेटर्सऑनफिगरेशन उप-निर्माण में बनाया गया है।

 @Configuration public class GeneratorsConfiguration { @Bean public NumberGenerator numberGenerator() { return new NumberGenerator(); } ... } 

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

 @Configuration @Import({GeneratorsConfiguration.class, ...}) public class ExternalContextConfiguration { ... } 

अब मैं कुछ उदाहरण दूंगा जिसमें नंबरगनेरेटर वर्ग के सिंगलटन बीन को वर्तमान एप्लिकेशन संदर्भ के कॉन्फ़िगरेशन में गलत तरीके से कॉन्फ़िगर किया गया है।

गलत कॉन्फ़िगरेशन 1. बाहरी एप्लिकेशन संदर्भ के मुख्य कॉन्फ़िगरेशन को आयात करना

सबसे खराब निर्णय जो हो सकता है।

 @Configuration @Import(ExternalContextConfiguration.class) public class CurrentContextConfiguration { ... } 

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

गलत कॉन्फ़िगरेशन 2. बाहरी अनुप्रयोग संदर्भ का आयात उपसंक्रमण

दूसरा विकल्प गलत है और व्यवहार में अक्सर सामने आता है।

 @Configuration @Import(GeneratorsConfiguration.class) public class CurrentContextConfiguration { ... } 

इस अवतार में, बाहरी मॉड्यूल की एक पूरी प्रतिलिपि अब नहीं बनाई गई है, हालांकि, हम फिर से नंबरगिनेटर वर्ग की दूसरी बीन प्राप्त करते हैं।

गलत कॉन्फ़िगरेशन 3. बीन में सीधे इंजेक्शन देखें, जहां हम नंबरगनेरेटर का उपयोग करना चाहते हैं

 public class OrderFactory { private final NumberGenerator numberGenerator; public OrderFactory() { ApplicationContext externalApplicationContext = getExternalContext(); numberGenerator = externalApplicationContext.getBean(NumberGenerator.class); } public Order create() { Order order = new Order(); int id = numberGenerator.next(); order.setId(id); order.setCreatedDate(new Date()); return order; } private ApplicationContext getExternalContext(){ ... } } 

इस विधि में, गुंजाइश सिंगलटन वाले सेम के दोहराव को हल किया जा सकता है। दरअसल, अब हम सेम को एक और एप्लिकेशन संदर्भ से पुन: उपयोग करते हैं और इसे फिर से नहीं बनाते हैं!

लेकिन इस तरह से:

1. विकसित वर्ग और इसकी इकाई परीक्षण की शिकायत करता है।
2. वर्तमान मॉड्यूल की सेम में नंबरगिनेटर वर्ग की बीन के स्वत: कार्यान्वयन को छोड़कर।
3. यह सामान्य मामलों में सिंगलटन बीन को इंजेक्ट करने के लिए लुकअप का उपयोग करने के लिए प्रथागत नहीं है।

इसलिए, इस तरह के एक समाधान एक समस्या के तर्कसंगत समाधान की तुलना में अनाड़ी वर्कअराउंड की तरह अधिक है।

इस बात पर विचार करें कि बाहरी अनुप्रयोग संदर्भ से बीन को ठीक से कैसे कॉन्फ़िगर किया जाए।

समाधान 1. विन्यास में बाहरी अनुप्रयोग संदर्भ से बीन प्राप्त करें

यह विधि एक अंतर के साथ गलत कॉन्फ़िगरेशन के 3 उदाहरण के समान है: हम कॉन्फ़िगरेशन में बाहरी संदर्भ से लुकअप करके एक बीन प्राप्त करते हैं, और सीधे बीन में नहीं।

 @Configuration public class CurrentContextConfiguration { @Bean public NumberGenerator numberGenerator() { ApplicationContext externalApplicationContext = getExternalContext(); return externalApplicationContext.getBean(NumberGenerator.class); } private ApplicationContext getExternalContext(){ ... } } 

अब हम इस सेम को अपने मॉड्यूल से सेम में स्वचालित रूप से एम्बेड कर सकते हैं।

समाधान 2. बाहरी अनुप्रयोग संदर्भ जनक बनाएं

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

मूल पैरामीटर के साथ कंस्ट्रक्टर का उपयोग करते हुए एक संदर्भ उदाहरण बनाते समय एक मूल संबंध निर्दिष्ट करना संभव है:

 public AbstractApplicationContext(ApplicationContext parent) { ... } 

या सेटर का उपयोग करें:

 public void setParent(ApplicationContext parent) { ... } 

यदि आवेदन संदर्भ xml में घोषित किया जाता है, तो हम निर्माणकर्ता का उपयोग कर सकते हैं

 public ClassPathXmlApplicationContext(String[] configLocations, ApplicationContext parent) throws BeansException { ... } 

निष्कर्ष

इस प्रकार, स्प्रिंग बीन्स को कॉन्फ़िगर करते समय सावधान रहें, लेख में सिफारिशों का पालन करें और उन बीन्स को कॉपी न करने का प्रयास करें जिनमें गुंजाइश सिंगलटन है। मुझे आपके सवालों के जवाब देने में खुशी होगी!