Java-buildpack: ऑटो-पुनर्विन्यास को अक्षम करने में सहायता

आप किस पुनर्गठन से बचने की कोशिश कर रहे हैं? व्यवहार में, स्प्रिंग ऑटो-रीकॉन्फ़िगरेशन JAR को क्लास पाथ पर रखा जाता है, लेकिन वास्तव में कोई ऑटो-रीकॉन्फ़िगरेशन नहीं हो सकता है। स्वतः-पुनर्विन्यास केवल तब होता है जब _both_ एक सेवा जो पुनर्विन्यास के लिए एक उम्मीदवार है _और_ एक बीन जो पुनर्विन्यास के लिए एक उम्मीदवार है, मौजूद है। इसलिए, आप उन सेवाओं को बाध्य न करके ऑटो-पुनर्गठन से बच सकते हैं जिनके साथ आप स्वत: पुन: कॉन्फ़िगर नहीं करना चाहते हैं। इसके अलावा, यदि कोई spring-cloud बीन्स परिभाषित हैं तो ऑटो-पुनर्विन्यास पूरी तरह से टाला जाता है।

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

@chrylis अंतिम बिंदु @nebhale ने ऑटो-

उस सब के साथ, हमने v1 में बंद होने के लिए ऑटो-रीकॉन्फिग की पेशकश की थी (देखें https://spring.io/blog/2011/11/04/using-cloud-foundry-services-with-spring-part-2 -ऑटो-पुनर्गठन)। आजकल, बिल्डपैक को फोर्क करने और किसी भी ज़रूरत को पूरा करने के लिए इसे संशोधित करने का एक बड़ा हथौड़ा है। तो क्या इस तरह के एक स्विच को अभी भी जावा बिल्डपैक में ही वारंट किया गया है, मैं @nebhale को कॉल करने

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

सभी घटकों की तरह, घटकों की सूची से इसकी प्रविष्टि को हटाकर स्वतः-पुनर्विन्यास को अक्षम किया जा सकता है। ऑटो-रीकॉन्फ़िगरेशन पर दस्तावेज़ीकरण के लिए सबसे अच्छा स्थान इसके गिटहब रिपोजिटरी और फ्रेमवर्क दस्तावेज़ीकरण पृष्ठ पर है ।

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

इसके अलावा, यदि कोई स्प्रिंग-क्लाउड बीन्स परिभाषित हैं, तो ऑटो-पुनर्गठन पूरी तरह से टाला जाता है।

मेरे अनुभव में उस व्यवहार में समय के मुद्दे हैं। यदि स्प्रिंग-क्लाउड बीन को एक प्रोफ़ाइल में परिभाषित किया गया है, तो इसे "पहले" घोषित बीन (यानी, एक विशिष्ट प्रोफ़ाइल के बाहर परिभाषित किया गया) के बाद पहचाना जा सकता है, जो पहले से ही ऑटो-रीकॉन्फ़िगरेशन द्वारा मंग किया गया है।

उदाहरण के लिए, एक कॉन्फ़िगरेशन दिया गया DataSource बीन्स को परिभाषित करता है: एक एम्बेडेड डेटा स्रोत और एक बाहरी डेटा स्रोत जो पर्यावरण/प्रोफ़ाइल के आधार पर भिन्न हो सकता है। जब तक आप एम्बेडेड डेटा स्रोत बीन परिभाषा को इनलाइन करने के लिए कॉन्फ़िगरेशन को

मैं मूल पोस्टर के समान कारणों से ऑटो-रीकॉन्फ़िगरेशन को भी अक्षम करना चाहूंगा: मैं नहीं चाहता कि कोई जादू हो जो मुझे समझ में न आए।
क्या यह बदल गया है? क्या बिल्डपैक को फोर्क करने के अलावा इसे किसी अन्य तरीके से अक्षम करना संभव है?

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

cf set-env myapp JBP_CONFIG_SPRING_AUTO_RECONFIGURATION '[enabled: false]'

अधिक जानकारी प्रलेखन में है https://github.com/cloudfoundry/java-buildpack#configuration -and-extension

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

मेनिफेस्ट फ़ाइल में ऐसा करने के लिए एक अलग प्रारूप की आवश्यकता होती है।

ये कोशिश करें,

JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '[enabled: false]'

अतिरिक्त :

क्या सेवाओं के कनेक्शन को आंशिक रूप से अक्षम करने का समर्थन करने के लिए इस ऑटो-पुनर्विन्यास पुस्तकालय की कोई योजना है? विशेष रूप से, हमारे उपयोग के मामले में, हमें एक अनुकूलित RedisConnectionFactory की आवश्यकता है (जैसा कि हम Azure Redis सेवा के लिए SSL कनेक्शन का उपयोग करते हैं), हालांकि, हम चाहते हैं कि यह ऑटो-पुनर्विन्यास lib हमारे RabbitMQ को फिर से कॉन्फ़िगर करे (जैसा कि हम PCF द्वारा प्रदान की गई RabbitMQ सेवा का उपयोग करते हैं)।