यहाँ क्या वास्तव में इस त्रुटि के साथ हो रहा है है: अनिवार्य रूप से servlets
XPages रहे हैं ... सब कुछ है कि एक सर्वलेट इंजन के शीर्ष पर एक XPage में होता है सिर्फ परतें। मूल रूप से दो प्रकार के डेटा होते हैं जो एक सर्वलेट कनेक्शन शुरू करने वाले किसी भी चीज़ को वापस भेज सकता है (जैसे ब्राउज़र): टेक्स्ट और बाइनरी।
एक सामान्य XPage टेक्स्ट भेजता है - विशेष रूप से, HTML। कुछ xAgents भी जेएसओएन या एक्सएमएल जैसे पाठ भेजते हैं। हालांकि, इनमें से किसी भी परिदृश्य में, डोमिनोज़ प्रतिक्रिया सामग्री भेजने के लिए जावा Writer का उपयोग करता है, क्योंकि राइटर्स को Character डेटा भेजने के लिए अनुकूलित किया गया है।
जब हमें बाइनरी सामग्री भेजने की आवश्यकता होती है, तो हम इसके बजाय OutputStream का उपयोग करते हैं, क्योंकि सामान्य बाइट डेटा भेजने के लिए धाराओं को अनुकूलित किया जाता है। तो अगर हम पीडीएफ, डीओसी/एक्सएलएस/पीपीटी, इमेज इत्यादि भेज रहे हैं, तो हमें एक स्ट्रीम का उपयोग करने की जरूरत है, क्योंकि हम बाइनरी डेटा भेज रहे हैं, टेक्स्ट नहीं।
पकड़ (जैसा कि आप जल्द ही देखेंगे, यह एक पन है) यह है कि हम केवल प्रति प्रतिक्रिया का उपयोग कर सकते हैं।
एक बार किसी भी HTTP क्लाइंट को बताया जाता है कि प्रतिक्रिया का प्रकार किस प्रकार है, यह उस सामग्री को संसाधित करने के बारे में धारणा बनाता है। इसलिए यदि आप इसे application/pdf की अपेक्षा करने के लिए कहते हैं, तो यह केवल बाइनरी डेटा प्राप्त करने की अपेक्षा करता है। इसके विपरीत, यदि आप इसे application/json की अपेक्षा करने के लिए कहते हैं, तो यह केवल चरित्र डेटा प्राप्त करने की अपेक्षा करता है। अगर प्रतिक्रिया में कोई डेटा शामिल है जो वादा किए गए सामग्री प्रकार से मेल नहीं खाता है, तो लगभग हमेशा संपूर्ण प्रतिक्रिया को अमान्य करता है।
तो डोमिनोज़ अपने अनंत ज्ञान में हमें केवल एक या दूसरे को एक ही अनुरोध में भेजने की अनुमति देता है, और अगर हम उस नियम का उल्लंघन करते हैं तो अपवाद फेंकता है।
दुर्भाग्य से ... अगर वहाँ हमारे कोड में किसी भी अपवाद है जब हम द्विआधारी सामग्री भेजने का प्रयास कर रहे हैं, डोमिनोज़ उपभोक्ता ... जो उत्पादन लेखक आह्वान करने के लिए एचटीएमएल रिपोर्टिंग भेजने का प्रयास करता करने के लिए रिपोर्ट करने के लिए है कि चाहता है कुछ गलत हो गया। सिवाय इसके कि आउटपुट स्ट्रीम पर हम पहले से ही एक हैंडल प्राप्त कर चुके हैं, इसलिए डोमिनोज़ को आउटपुट लेखक पर एक संभाल पाने की अनुमति नहीं है, क्योंकि यह केवल प्रति प्रतिक्रिया का उपयोग करने के खिलाफ अपने नियम का उल्लंघन करेगा। बदले में, आपके द्वारा रिपोर्ट किए गए अपवाद को फेंकता है, अपवाद को मास्क करना जो वास्तव में समस्या का कारण बनता है (आपके मामले में, शायद ClassNotFoundException)।
तो हम कैसे सुनिश्चित करते हैं कि हम वास्तविक समस्या देखें, और यह गलत दिशा नहीं है? हम try:
try {
/*
* Move all your existing code here...
*/
} catch (e) {
print("Error generating dynamic PDF: " + e.toString());
} finally {
facesContext.responseComplete();
}
दो कारण हैं इस एक पसंदीदा तरीका है: कुछ हमारे कोड के साथ गलत हो जाता है
- , तो हम न दें डोमिनोज़ इसके बारे में एक अपवाद फेंक देते हैं। इसके बजाए, हम इसे लॉग इन करते हैं (कंसोल और लॉग पर भेजने के लिए
print का उपयोग करने के बजाय, आप इसे ओपनलॉग पर भी टॉस कर सकते हैं, या जो भी आपकी पसंदीदा लॉगिंग तंत्र हो सकती है)। इसका मतलब है कि डोमिनोज़ उपयोगकर्ता को त्रुटि की रिपोर्ट करने का प्रयास नहीं करता है, क्योंकि हमने वादा किया है कि हमने पहले से ही इसे स्वयं रिपोर्ट किया है।
- महत्वपूर्ण
facesContext.responseComplete() कॉल finally ब्लॉक करने के लिए आगे बढ़ (है जो अंतत: डोमिनोज़ बताता है अपनी खुद की किसी भी सामग्री को न भेजने के लिए) से, यह यह निष्पादित हो जाएगा सुनिश्चित करता है। अगर हमने इसे try ब्लॉक के अंदर छोड़ दिया है, तो अपवाद होने पर यह छोड़ा जाएगा, क्योंकि हम सीधे catch पर छोड़ देंगे ... भले ही डोमिनोज़ हमारे अपवाद की रिपोर्ट नहीं कर रहा है क्योंकि हमने इसे पकड़ा है, फिर भी यह कोशिश करने का प्रयास करता है प्रतिक्रिया लेखक क्योंकि हमने यह नहीं बताया था।
यदि आप उपरोक्त पैटर्न का पालन करते हैं, और आपके कोड में कुछ गड़बड़ है, तो ब्राउज़र को अधूरा या भ्रष्ट फ़ाइल प्राप्त होगी, लेकिन लॉग आपको बताएगा कि क्या त्रुटि हुई है, इसके बजाय कुछ भी नहीं है समस्या के मूल कारण के साथ करो।
ठीक है, मैं मूर्ख हूं, मैंने इसे समझ लिया, मेरा आयात xAgent में पैकेज विवरण गलत था। –