java.lang.ClassCastException का अर्थ: SomeClass SomeClass

Question

के साथ असंगत मैं XPages आवेदन में कभी कभी अपवाद सामना कर रहा था:

java.lang.ClassCastException: someClass incompatible with someClass. 

दोनों उल्लेख किया कक्षाएं एक ही हैं, यह सत्र सेम के रूप में इस्तेमाल वर्ग है। मैं अपनी समस्या को कवर करने वाली किसी भी चीज़ को Google पर नहीं कर पा रहा था। इसके लिए सामान्य स्पष्टीकरण डिजाइन तत्वों में बदल गया था, न कि मेरे मामले में।

XPage एप्लिकेशन अनुपस्थित हो जाता है (सत्र बीन someClass का उपयोग कर पृष्ठ) उस क्षण से, http कार्य को पुनरारंभ करने तक, या चेहरे-config.xml का पुनर्विक्रय।

कुछ मामलों में ऐसे अन्य अपवाद से संबंधित है:

com.ibm.jscript.InterpretException: Script interpreter error, line=x, col=y: 
Java method 'method(signature containg someClass)' 
on java class 'someOtherClass' not found 

इस व्यवहार के पीछे क्या है?

Answer 1

फिलिप Riand ईमेल द्वारा इस explaned:

इस वर्ग के कलाकारों इसलिए होता है क्योंकि एक ही कक्षा 2 अलग वर्ग लोडर द्वारा दो बार लोड किया गया था। इस प्रकार, जावा स्टैंडपॉइंट से, वे अलग हैं और कलाकार विफल रहता है।

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

अंत में, चेहरे-config.xml को एक वर्कअराउंड के रूप में सहेजते हैं। जब यह फ़ाइल सहेजी जाती है, तो पूरे मॉड्यूल को स्कोप समेत स्मृति से त्याग दिया जाता है, यह बताता है कि यह क्यों काम करता है। अपनी कस्टम जावा क्लास में बदलाव करना मॉड्यूल को फिर से लोड करना और समस्या को हटाना चाहिए।

तो यह sessionScope में सेम (यहां तक ​​कि परोक्ष रूप से) डालने लगता है या applicationScope कारण है।

Answer 2

यदि एक ही कक्षा फ़ाइल अलग-अलग वर्ग लोडर में लोड की जाती है, तो दो परिणामी जावा क्लासेस समान कक्षा नहीं हैं; आपको दूसरे की अपेक्षा करने वाले कार्यों के लिए एक के उदाहरण पारित करने की अनुमति नहीं दी जाएगी। आम तौर पर, यदि आप इस तरह की समस्या देख रहे हैं, तो ऐसा इसलिए है क्योंकि आपके पास कई बच्चे क्लासलोडर हैं जो एक जार फ़ाइल तक पहुंच सकते हैं जो उनके सामान्य अभिभावक क्लासलोडर को दिखाई नहीं दे रहा है। आपको एक विशेष वेबैप निर्देशिका (उदाहरण के लिए) की बजाय एक सामान्य लाइब्रेरी निर्देशिका में "someclass" युक्त जार को स्थानांतरित करने की आवश्यकता हो सकती है।

Answer 3

बस यहां अपना अनुभव डालें।

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