2009-01-19 13 views
5

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

अग्रिम धन्यवाद।

उत्तर

11

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

संपादित करें: मैं इस बिट पहले लिखने के लिए योजना बनाई थी, लेकिन एक ट्रेन यात्रा के अंत तक बाधित हो गया ...

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

+1

मेरे अनुभव में, क्लासपाथ में पहले कक्षाएं विश्वसनीय रूप से लोड की गई हैं, जबकि बाद के संस्करण नहीं हैं। – Cogsy

+0

हाँ इसे काम करना चाहिए, लेकिन यह अभी भी कुछ कक्षाओं को अपडेट करने के लिए एक सुंदर मूर्ख तरीका है –

+1

और बदले गए इंटरफेस पर निर्भरता अभी भी आपको जला सकती है।साथ ही, एक जटिल क्लासलोडर संरचना क्लासलोडिंग को असफल होने का कारण बन सकती है यदि सभी शामिल क्लासपाथ अपडेट नहीं होते हैं। – Darron

1

हां, यह संभव है कि इसे अपने मूल जार की तुलना में क्लासपाथ पर रखकर संभव हो। हालांकि, आपके क्लासपाथ के आदेश पर भरोसा करना हमेशा खुशी का कारण नहीं बनता है। मुझे यकीन नहीं है कि यह जावा भाषा स्पेक में भी दस्तावेज है; यदि नहीं, तो यह अलग JVMs और एक ही JVM के विभिन्न संस्करणों के लिए तोड़ने जा रहा है।

इसके बजाय, वर्तमान कोडबेस में नई सुविधा को एकीकृत करने के लिए यथार्थवादी समय सीमा उद्धृत करने पर विचार करें। यह शायद वह उत्तर नहीं है जिसे आप ढूंढ रहे हैं।

3

हां और नहीं, यह आपके पर्यावरण पर निर्भर करता है।

यदि आप ओएसजीआई का उपयोग करते हैं, और आपके संस्करणों को नियंत्रित करते हैं, तो यह एक उच्च संस्करण में निर्यात किए गए पैकेज के साथ एक नया बंडल स्थापित करने का मामला है (मान लें कि आपकी संस्करण सीमाएं पर्याप्त हैं)।

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

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

2

जवाब है कि लोगों को वे classpath में स्थान ले रही हैं पहले अद्यतन कक्षाएं लगाने निर्धारित सही हैं, केवल प्रदान की मूल जार सील या हस्ताक्षरित नहीं है।

+1

जार पर हस्ताक्षर किए जाने पर यह काम नहीं करता है। – studgeek

0

संभवतः आपको इस विशिष्ट मामले की आवश्यकता से अधिक, लेकिन आम तौर पर यदि आप केवल मौजूदा कक्षा में बदलाव या वृद्धि करना चाहते हैं तो आप load-time weaving के साथ AspectJ का भी उपयोग कर सकते हैं।