ओएसजीआई: क्लासपाथ स्थिरता सुनिश्चित करने के लिए कैसे?

Question

ओएसजीआई दस्तावेज के अनुसार, ओएसजीआई को क्लासपाथ समस्याओं को रोकने में मदद के लिए डिज़ाइन किया गया है।

उदाहरण के लिए, "काम करते हुए OSGi" से:

ClassNotFoundExceptions जब आपके आवेदन शुरू करने क्योंकि वर्ग पथ सही नहीं था। ओएसजीआई यह सुनिश्चित करके मदद कर सकता है कि कोड कोड निष्पादित करने की अनुमति देने से पहले निर्भरताएं संतुष्ट हैं।

हालांकि, बाद से हम OSGi के लिए हमारी जावा आवेदन स्विच कर लें, मैं और अधिक ClassNotFoundExceptions और विशेष रूप से पहले से कहीं ज्यादा NoClassDefFoundErrors देखते हैं। कक्षाएं जिन्हें पहले ठीक से लोड किया गया था, अब ओएसजीआई क्लासलोडर द्वारा नहीं पाए जाते हैं, और इससे भी बदतर: आपको रन-टाइम पर त्रुटि मिलती है, जिसका अर्थ यह है कि आप आसानी से इसके आवेदन के हर कोने का परीक्षण करके इसे आसानी से जांच नहीं सकते हैं।

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

java.lang.NoClassDefFoundError: org/w3c/dom/Node 

तो, OSGi वास्तव में यह हल करती है और अधिक से अधिक classpath समस्याएं पैदा कर रहा है?

और सबसे महत्वपूर्ण बात यह है कि मैं कैसे जांच सकता हूं कि मेरे क्लास-पथ सभी आवश्यक आयात-पैकेज विवरण आदि के साथ संगत है, से पहले मैंने बग रिपोर्ट में उनके बारे में पढ़ा?

Answer 1

एक OSGi आवेदन अगर अपने प्रकट सही है नहीं ClassNotFoundExceptions और NoClassDefFoundErrors फेंक देते हैं। यही है, आपको ओएसजीआई को बताने की ज़रूरत है जो आपके बंडल का उपयोग करता है; यदि आप इसे सही या ईमानदारी से नहीं करते हैं, तो ओएसजीआई आपकी मदद नहीं कर सकता है। दूसरे शब्दों में: जीआईजीओ (कचरा, कचरा आउट)।

उदाहरण के लिए, आप पैकेज org.w3c.dom का उपयोग करते हैं लेकिन आप इसे अपने Import-Package कथन में सूचीबद्ध नहीं करते हैं। इसलिए ओएसजीआई यह नहीं जानता कि आपको उस पैकेज तक पहुंच की आवश्यकता है, और इसलिए जब आप वास्तव में उस पैकेज से कक्षाएं लोड करने का प्रयास करते हैं, तो वे उपलब्ध नहीं हैं।

तो, आपको यह सुनिश्चित करना होगा कि आपके Import-Package कथन आपके बंडलों का वास्तव में उपयोग किए जाने वाले पैकेजों के संबंध में सटीक है। अच्छी खबर यह है कि "बीएनडी" टूल सभी सांख्यिकीय रूप से संदर्भित संकुलों को खोजने के लिए बाइटकोड विश्लेषण का उपयोग करके बंडल मैनिफेस्ट उत्पन्न करके आपके लिए ऐसा कर सकता है।

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

Answer 2

मुझे लगता है कि यहां समस्या यह है कि आप अपने बंडल द्वारा उपयोग किए गए पैकेज/कक्षाओं का सही सेट निर्दिष्ट नहीं कर रहे हैं (आपके मैनिफ़ेस्ट में आयात-पैकेज निर्देश का उपयोग करके)। जब तक ओएसजीआई उन लोगों के बारे में नहीं जानता, यह वास्तव में मदद नहीं कर सकता!

सुनिश्चित नहीं हैं कि कैसे आप अपने OSGi बंडलों का निर्माण कर रहे हैं, लेकिन आप Maven bundle plugin की जांच करनी चाहिए, कि स्पष्ट रूप से (कम से कम संकलन समय लोगों के लिए) आयात-संकुल को निर्दिष्ट करने की समस्याओं को हल करती है। http://wso2.org/library/tutorials/develop-osgi-bundles-using-maven-bundle-plugin#Importing%20packages देखें।

Answer 3

मैं केंद्रीय प्रश्न का उत्तर नहीं दे रहा हूं, लेकिन इसी तरह की समस्या के लिए अपना समाधान प्रदान कर रहा हूं।

मेरे मामले में, मैं इस वर्ग संरचना था:

• interface javax.script.ScriptEngineFactory
• class pkga.A implements ScriptEngineFactory
• class pkgb.B extends A

मेरा प्राथमिक परियोजना कोड वर्ग B में था और इस विस्तारित वर्ग A में एक निर्भर जार। का उपयोग करते हुए

<Export-Package>pkgb.*</Export-Package> 

अपर्याप्त था, मैं javax.script.ScriptEngineFactory की कमी के बारे में शिकायत कोई त्रुटि हुई। यह अजीब है क्योंकि यह मानक जेडीके 8 का हिस्सा है, ध्यान दें कि पैकेज pkgbमें कोड स्पष्ट रूप से संदर्भ javax.script.* नहीं था; शायद मेनिफेस्ट लेखक को यह नहीं पता था कि इस इंटरफ़ेस को निर्यात करने की आवश्यकता है?

मैंने पाया निर्यात-पैकेज के निर्देश को यह अतिरिक्त समस्या

<Export-Package>pkgb.*,javax.script.*</Export-Package>