सेवा शुरू होने पर ओएसजीआई सेवा को अक्षम करने का सही तरीका क्या है?

Question

मैंने एक खुलासा (घोषणात्मक) सेवा के साथ एक ओएसजीआई बंडल बनाया है। यदि मैं सक्रिय करता हूं, तो ध्यान दें कि कुछ अस्वस्थ है जैसे कि मैं सेवा प्रदान नहीं कर सकता, मुझे इसे उजागर होने से रोकने की आवश्यकता है। फिलहाल सक्रियण समारोह तो दिखाई देता है:

public void activate(ComponentContext context, Map<String, Object> properties) { 
    try { 
     ... 
    } 
    catch(Exception e) { 
     throw new ComponentException("Some reason"); 
    } 
} 

मैं नहीं मिल सकता है:

public void activate(ComponentContext context, Map<String, Object> properties) { 
    pid = (String) properties.get(Constants.SERVICE_PID); 
    try { 
     ... 
    } 
    catch(Exception e) { 
     context.disableComponent(pid); 
    } 
} 

एक अन्य विकल्प सिर्फ लपेट/इस तरह अपवाद प्रचार (या एक नया फेंक, निर्भर करता है) के लिए है OSGi Service Platform Service Compendium में घोषणात्मक सेवाओं पर अनुभाग में निर्दिष्ट सही व्यवहार, लेकिन मुझे कुछ

Answer 1

हम्म, मेरे लिए यह तर्कसंगत लगता है कि कोई त्रुटि होने पर अपवाद को फेंक दिया जाना चाहिए। असल में, आप जो कर रहे हैं वह प्रारंभ विधि में बंडल एक्टिवेटर के व्यवहार की नकल कर रहा है। बंडल सक्रिय स्थिति में प्रवेश करता है जब प्रारंभ विधि अपवाद के बिना वापस आती है (अन्यथा यह RESOLVED में बनी हुई है)। मुझे डीएस विनिर्देशन में कुछ हद तक उपयुक्त अनुच्छेद मिला (मैंने दिलचस्प भाग को हाइलाइट किया):

एक घटक उदाहरण को निष्क्रिय होने से पहले सक्रियण को पूरा करना होगा। एक बार घटक कॉन्फ़िगरेशन निष्क्रिय हो जाने पर या अपवाद के कारण सक्रिय करने में विफल रहता है, एससीआर को सभी घटक की बाध्य सेवाओं को अनइंड करना होगा और सक्रियण से जुड़े घटक उदाहरण के सभी संदर्भों को त्यागना होगा। OSGi 4.2 cmpn spec

में

धारा 112.5.6 P.320 मैं मानता हूँ कि यह साफ नहीं है, इसलिए यदि आप सुरक्षित पक्ष (खेद की तुलना में बेहतर सुरक्षित) पर होना चाहता हूँ, मैं करने के लिए सिफारिश करेंगे संयोजन करें (spec द्वारा अनुमत)।

public void activate(ComponentContext context, Map<String, Object> properties) { 
    try { 
     ... 
    } catch(Exception e) { 
     context.disableComponent((String) properties.get(Constants.SERVICE_PID)); 
     // not sure if a CE is best here... Maybe just rethrow the original one 
     throw new ComponentException("Some reason"); 
    } 
} 

चीयर्स, मिरको

Answer 2

एक घटक खुद को अक्षम करने के लिए बहुत एक उपयुक्त OSGi डिजाइन होने की संभावना नहीं है। स्थिति में सुधार होने पर घटक को क्या सक्षम करेगा? सक्षम/अक्षम राज्य सक्रिय/निष्क्रिय से भिन्न तर्कसंगत स्तर होने का इरादा है।

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

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