मैं जानना चाहता हूं कि "इस वर्ग में से एक को लोड होने पर इस प्लग-इन को सक्रिय करें" ग्रहण मेनिफेस्ट संपादक में चेक-बॉक्स उपयोगी है।एक्लिप्स प्लगइन्स की आलसी सक्रियण
मैंने सोचा कि ग्रहण हमेशा "आलसी प्रारंभिक" दृष्टिकोण का उपयोग करता है। क्या यह विकल्प प्लगइन के बंडलएक्टिवेटर कक्षा से संबंधित है? प्रारंभिकता के लिए प्रारंभिक कुछ अलग है?
Here एक समान प्रश्न है, लेकिन मैं इसे पूरी तरह से समझ नहीं पा रहा हूं।
बॉक्स को चिह्नित का कारण बनता है निम्नलिखित हैडर प्रकट में स्थापित किया जाना:
Bundle-ActivationPolicy: lazy
मैं इस के साथ कैसे "शुद्ध" OSGi सौदों के साथ शुरू करेंगे। अगर बंडल START_ACTIVATION_POLICY ध्वज के साथ शुरू होता है तो बंडल STARTING स्थिति में प्रवेश करता है लेकिन सक्रियकर्ता की प्रारंभ() विधि लागू नहीं होती है और बंडल के लिए क्लासलोडर आवंटित नहीं किया जाता है। बंडल शुरू होने में रहता है, किसी भी कारण से, कक्षा को बंडल से लोड करने की आवश्यकता होती है। उस बिंदु पर एक क्लासलोडर आवंटित किया जाता है और सक्रियकर्ता (यदि कोई है) तत्काल होता है और अनुरोध की गई कक्षा लोड होने से पहले इसकी प्रारंभ() विधि लागू की जाती है।
हालांकि ग्रहण शीर्ष पर अतिरिक्त अर्थशास्त्र परतें। पृष्ठभूमि के रूप में, ग्रहण हमेशा अपने स्टार्ट-अप समय को न्यूनतम रखने के लिए बंडलों को शुरू करने से बचने का प्रयास करता है। डिफ़ॉल्ट रूप से बंडलों का एक बहुत ही छोटा कोर सेट प्रारंभ होता है (सूची कॉन्फ़िगरेशन/config.ini में होती है) और इनमें से एक को पी 2 "सरल कॉन्फ़िगरेटर" कहा जाता है। सरल कॉन्फ़िगरेटर बंडल की तलाश करता है जिसमें हैडर है और यह उन्हें START_ACTIVATION_POLICY ध्वज से शुरू करता है ... इसलिए इन बंडलों को ऊपर वर्णित अनुसार "आलसी" शुरू किया जाएगा।
महत्वपूर्ण मुद्दा यह है कि सभी अन्य बंडलों कि हैडर शामिल नहीं है ग्रहण के तहत सभी प्रारंभ नहीं किया जा जाएगा। वे RESOLVED राज्य में रहेंगे, उनके कार्यकर्ताओं को नहीं बुलाया जाएगा, और यदि उनमें कोई घोषणात्मक सेवा घटक शामिल है तो उन्हें लोड नहीं किया जाएगा। ऐसा इसलिए है क्योंकि घोषणात्मक सेवाएं केवल उन बंडलों को देखती हैं जो सक्रिय या प्रारंभिक स्थिति में हैं।
इसलिए हेडर का उपयोग करने का मुख्य कारण यह है कि अगर हम एक्वाइसेज के तहत काम करने की आवश्यकता वाले घोषणात्मक सेवा घटकों वाले बंडल को लिखना चाहते हैं।
अन्य वातावरण में शीर्षलेख का उपयोग करने की आवश्यकता नहीं है। सबसे सामान्य ओएसजीआई ऐप्स चुनिंदा रूप से बंडलों के उप-समूह को शुरू करने की कोशिश करने के बजाए सभी बंडल शुरू करते हैं। ध्यान दें कि इसका मतलब यह नहीं है कि ओएसजीआई ऐप्स आलसी लोडिंग के बारे में चिंता नहीं करते हैं! घोषणात्मक सेवाएं बंडल क्लास लोडिंग ट्रिगर के साथ गड़बड़ किए बिना आलसी लोडिंग का समर्थन करती हैं। मेरी राय में ग्रहण यह गलत हो गया है और बंडल जीवन चक्र में अनावश्यक जटिलता को जोड़ा है। फिर भी यदि आप एक्लिप्स में चल रहे हैं तो आपके पास इसकी सीमा के साथ समझने और काम करने के अलावा कोई विकल्प नहीं है।
अच्छा जवाब। फिर भी मेरे पास कुछ प्रश्न हैं। 1) जब मैं ऑटो कॉन्फ़िगर करने के लिए उत्पाद कॉन्फ़िगरेशन में प्लगइन सेट करता हूं: सत्य, तो यह बंडल-एक्टिवेशन पॉलिसी हेडर के बावजूद शुरू किया जाएगा? 2) वैसे भी शुरू करने का मतलब क्या है? आप कहते हैं "वे बिल्कुल शुरू नहीं होंगे"। जब प्लगइन शुरू नहीं होता है तो प्लगइन कैसे काम कर सकता है? – Behnil
1) हां। 2) शुरू हुआ मतलब है कि बंडल के सक्रियकर्ता को बुलाया जाता है और डीएस घटक तत्काल/प्रबंधित होते हैं। एक गैर-प्रारंभिक बंडल (यानी RESOLVED) अभी भी निर्भरता प्रदान कर सकता है, उदा। निर्यात पैकेज जिन्हें अन्य बंडलों द्वारा लोड किया जा सकता है। यह निष्क्रिय पुस्तकालयों जैसी चीजों के लिए उपयोगी है। –
वैसे, डीएस आप किस बारे में बात कर रहे हैं। वे मेनू एक्सटेंशन, वर्कबेंच पार्ट्स योगदान आदि जैसे सभी विस्तार बिंदु हैं?क्योंकि जब मैं एक प्लगइन बनाता हूं जो एक परिप्रेक्ष्य में एक दृश्य योगदान देता है और इसे बंडल-एक्टिवेशन पॉलिसी सेट नहीं करता है: आलसी, दृश्य अभी भी दिखाई दे रहा है !? – Behnil