एप्लीकेशन सर्वर में क्लास लोडिंग, जेबॉस एएस 7 की विशेषताएं

जावा को कक्षाओं के गतिशील लोडिंग की विशेषता है। खोज और लोड करने के लिए, क्लास लोडर को सौंपने के तंत्र का उपयोग किया जाता है। जावा एसई वातावरण में, उनकी संख्या 2-3 तक सीमित है, लेकिन एप्लिकेशन सर्वर में यह 10 पदानुक्रमित क्लास लोडर तक पहुंचता है। यह लंबे लॉन्च समय (आमतौर पर एक मिनट से) और अनुप्रयोगों की तैनाती के बारे में बताता है।

JBoss AS 7 में, डेवलपर्स स्टार्टअप समय को कम करने में सक्षम थे (एक वर्कस्टेशन पर 3-4 सेकंड में एक खाली ऐप्ज़रवर शुरू होता है)। इस एप्लिकेशन सर्वर में नए क्लास लोडिंग सिस्टम द्वारा इसकी सुविधा दी गई थी। इस दृष्टिकोण में अभी भी इसकी कमियां हैं।

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

जावा में कक्षाएं लोड हो रही हैं

जावा लैंग्वेज स्पेसिफिकेशन के अनुसार , जेवीएम गतिशील रूप से कक्षाओं को लोड, बाइंड और इनिशियलाइज़ करता है। क्लास लोडर के पदानुक्रम द्वारा कक्षा की खोज और लोडिंग की जाती है।

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

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

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

स्वाभाविक रूप से, वर्ग का पता नहीं लगाया जा सकता है - फिर एक त्रुटि लोड हो रही है, एक नियम के रूप में, जेवीएम दुर्घटना के लिए अग्रणी है अगर यह अवरोधन नहीं है (जैसा कि एप्लिकेशन सर्वर करते हैं)।

सर्वलेट कंटेनर (टॉमकैट, जेट्टी) में सामान्य लोडिंग संरचना

इस प्रकार के वातावरण में, क्लास लोडर का पदानुक्रम, निश्चित रूप से, जटिल है। सिस्टम क्लास लोडर के बाद, जो कि सर्वलेट कंटेनर को चलाने के लिए डिज़ाइन किया गया है, खोज को श्रृंखला के नीचे रखा गया है।

कंटेनर में एम्बेड किए गए प्रत्येक एप्लिकेशन के लिए, अपना स्वयं का क्लास लोडर बनाया जाता है, जो WEB-INF / कक्षाओं में कक्षाएं और WEB-INF / lib में जार-फाइलें (इस एप्लिकेशन के युद्ध के भीतर सभी) के लिए खोज करता है।

इसके बाद, कॉमन क्लास लोडर के लिए एक प्रतिनिधिमंडल होता है, जो सभी क्लाइंट्स के लिए लाइब्रेरी की खोज करता है (tomcat के मामले में CATALINA_HOME / lib)।

एप्लिकेशन सर्वर

शेष कहानी ग्लासफ़िश ऐप सर्वर के साथ लोडिंग कक्षाओं के बारे में है। जैसा कि अपेक्षित था, लंबी बूट श्रृंखला में पहला बूटस्ट्रैप क्लास लोडर। इसके बाद, नियंत्रण सार्वजनिक एपीआई क्लास लोडर में स्थानांतरित कर दिया जाता है, जो एप्लिकेशन सर्वर द्वारा निर्यात किए गए जावा ईई स्टैक और अन्य एपीआई के वर्गों, इंटरफेस और एनोटेशन के लिए जिम्मेदार है। अगला एक सामान्य क्लास लोडर है जो हमारे लिए टॉमकैट से परिचित है, जो कि पूरे ऐप-सर्वर के लिए पुस्तकालयों के लिए सामान्य है। श्रृंखला में अगला कनेक्टर क्लास लोडर है , जो सभी अनुप्रयोगों को जेसीए तक पहुंचने की अनुमति देता है। उसके बाद, नियंत्रण को जीवनचक्र वर्ग लोडर में स्थानांतरित कर दिया जाता है। यह अनुप्रयोगों में सेम के जीवनचक्र को नियंत्रित करने वाली कक्षाओं को लोड करने के लिए डिज़ाइन किया गया है। अगला नायक ऐपलिब क्लास लोडर है , जो आम के समान है, लेकिन कुछ एप्लिकेशन समूहों के साथ काम करता है। और अंत में, पुरालेख कक्षा लोडर को ट्रिगर किया जाता है , WAR / EAR / RAR / EJB-JAR, आदि से कक्षाओं के साथ काम कर रहा है।

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

कथा नायक जे.बॉस एएस 7 की विशेषताएं

JBoss AS 6, क्लास लोडर ग्लासफिश की संरचना में बहुत समान है। प्रारंभ समय से - इसी तरह। क्या मौलिक रूप से संस्करण 7 को पुनर्प्राप्त करता है? उसे डेवलपर्स का ध्यान क्यों आया?

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

तो, चलिए मुद्दे के तकनीकी पक्ष की ओर बढ़ते हैं। आपने ऐसी गति कैसे प्राप्त की? पदानुक्रमित क्लास लोडर के धीमे संचालन की समस्या को हल करने का आधार JBoss मॉड्यूल है । यह परियोजना लोडिंग कक्षाओं के लिए एक मॉड्यूलर (पदानुक्रमित के बजाय) दृष्टिकोण का लक्ष्य रखती है। मॉड्यूल के एक छोटे से सेट के भीतर खोज की जाती है। सवाल उठता है कि पर्यावरण को कैसे पता चल सकता है कि कौन से मॉड्यूल देखने हैं?

यह, दुर्भाग्य से, केवल निर्भरता मॉड्यूल को स्पष्ट रूप से सूचीबद्ध करके हल किया गया है। ऐसा करने के लिए, निर्भरता क्षेत्र जिसमें निर्भरताएं सूचीबद्ध हैं, को उसके प्रकट होने वाले युद्ध में शामिल किया गया है।

अपने नाम से, सर्वर को इस मॉड्यूल का वर्णन करने वाले xml का पता चलता है: इसमें शामिल जार फ़ाइलों का एक सेट, और मॉड्यूल जिस पर यह निर्भर करता है।

मावेन का उपयोग करना

निर्माण के लिए मावेन का उपयोग करते समय, पैकेज में कुछ निर्भरता में परिणाम प्रदान करने के लिए यह दृष्टिकोण pom.xml में प्रदान किया जा रहा है। उदाहरण के लिए, slf4j का उपयोग करते समय, यह इस तरह दिखेगा:

<dependencides> <dependecy> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.6.1</version> <scope>provided</scope> </dependecy> <!-- ... --> </dependencies> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <configuration> <archive> <manifestEntries> <Dependencies>org.slf4j</Dependencies> </manifestEntries> </archive> </configuration> </plugin> <!-- ... --> </plugins> </build> 

IntelliJ IDEA में डिबगिंग

इस आईडीई के सभी आकर्षण के बावजूद, इसमें अक्सर अप्रिय दोष पाए जाते हैं। उदाहरण के लिए, मावेन के साथ बातचीत करते समय। पिछले पैराग्राफ से कॉन्फ़िगरेशन का उपयोग करके किसी प्रोजेक्ट को डीबग करने का प्रयास करते समय, यह पता चला है कि मावेन द्वारा एकत्र की गई कलाकृति सही ढंग से काम करती है,
और जब आइडिया से तैनाती की जाती है, तो NoClassDefFoundError उड़ जाता है। यह इस तथ्य के कारण है कि आईडीईए pom.xml से डेटा का उपयोग नहीं करता है, लेकिन डिपेंडेंसी क्लॉज की अनुपस्थिति से बहिष्कृत अपने MANIFEST.MF को उत्पन्न करता है।
आप इस प्रकार की अपनी अभिव्यक्ति बनाकर इस व्यवहार को प्राप्त कर सकते हैं:

Manifest-Version: 1.0
Dependencies: org.slf4j

इस तरह के वर्कअराउंड का एक स्पष्ट दोष दो स्थानों पर निर्भरता की जानकारी का दोहराव है।