2010-09-13 10 views
9

मैंने नमूना परियोजनाओं का एक गुच्छा देखा है और मैं एक सामान्य सर्वोत्तम अभ्यास को परेशान नहीं कर सकता। मैंने देखा है कि स्प्रिंग बीन कॉन्फ़िगरेशन फ़ाइलें कभी-कभी src/main/webapp/WEB-INF निर्देशिका में जाती हैं। मैं इस तरह web.xml में एक सर्वलेट परिभाषा के साथ साथ संयोजन के रूप में इस देखा है:वसंत बीन कॉन्फ़िगरेशन फ़ाइलों को एक मेवेन युद्ध मॉड्यूल में कहां जाना है?

<servlet> 
    <servlet-name>my-stuff</servlet-name> 
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> 
    <init-param> 
     <param-name>contextConfigLocation</param-name> 
     <param-value>/WEB-INF/my-stuff-servlet.xml</param-value> 
    </init-param> 
    <load-on-startup>1</load-on-startup> 
</servlet> 

लेकिन मैं यह भी देखा है सेम config फ़ाइलों web.xml शीर्ष स्तर के भीतर शामिल - यानी एक सर्वलेट के बाहर। इसका क्या मतलब है? क्या यह क्रॉस-सर्वलेट बीन्स के लिए है? कभी-कभी यह src/main/webapp/WEB-INF निर्देशिका में है और कभी-कभी यह src/main/resources में है। इसके अलावा मैंने src/main/resources में बस सब कुछ के साथ WAR मॉड्यूल में परिभाषित अन्य बीन कॉन्फ़िगरेशन फ़ाइलों को देखा है।

मैंने स्प्रिंग प्रलेखन को पढ़ और पढ़ा है, लेकिन मुझे मिला एकमात्र सम्मेलन यह है कि डिफ़ॉल्ट रूप से एक सर्वलेट संदर्भ कॉन्फ़िगर फ़ाइल src/main/webapp/WEB-INF निर्देशिका {servlet-name}-servlet.xml नामक निर्देशिका में होनी चाहिए।

तो सबसे अच्छा अभ्यास क्या है और क्यों?

उत्तर

12

वसंत में आवेदन संदर्भ पदानुक्रम बना सकते हैं जहां बाल संदर्भ में मूल संदर्भ में परिभाषित बीन्स तक पहुंच है।

  • रूट वेब अनुप्रयोग संदर्भ ContextLoaderListener द्वारा लोड:

    एक ठेठ वसंत MVC वेब अनुप्रयोग दो स्तरों के साथ एक पदानुक्रम में शामिल है। डिफ़ॉल्ट रूप से इस संदर्भ का कॉन्फ़िगरेशन स्थान applicationContext.xml है और <context-param>contextConfigLocation नामक कॉन्फ़िगर किया जा सकता है, यानि web.xml के शीर्ष स्तर पर। इस संदर्भ में आमतौर पर एक कोर अनुप्रयोग तर्क होता है।

  • Servlet-specifc संदर्भ DispatcherServlet द्वारा लोड किया गया। इसका कॉन्फ़िगरेशन स्थान डिफ़ॉल्ट रूप से <servletname>-servlet.xml है और <init-param>contextConfigLocation नामक कॉन्फ़िगर किया जा सकता है, यानी सर्वलेट स्तर पर। इस संदर्भ में आमतौर पर स्प्रिंग एमवीसी से संबंधित सामान (नियंत्रक, आदि) होते हैं क्योंकि DispatcherServlet स्प्रिंग एमवीसी का हिस्सा है।

उत्तरार्द्ध संदर्भ पूर्व का एक बच्चा है।

यदि वेब एप्लिकेशन प्रस्तुति ढांचे के रूप में स्प्रिंग एमवीसी का उपयोग नहीं करता है, तो इसमें DispatcherServlet और इसके संदर्भ नहीं हैं। कुछ बेहद सरल स्प्रिंग एमवीसी नमूने में ContextLoaderListener और रूट संदर्भ नहीं है (हालांकि, आपको स्प्रिंग सुरक्षा जैसे क्रॉस-सर्वलेट कार्यक्षमता के लिए रूट संदर्भ की आवश्यकता है)।

वेब एप्लिकेशन की कॉन्फ़िगरेशन फ़ाइलें डिफ़ॉल्ट रूप से वेबएप के रूट फ़ोल्डर में स्थित होती हैं। हालांकि, उन्हें कक्षा में रखा जा सकता है (यानी src/main/webapp में), इस मामले में उन्हें classpath: उपसर्ग के माध्यम से एक्सेस किया जा सकता है। यह उपयोगी हो सकता है यदि आप इनमें से कुछ फ़ाइलों को सर्वलेट कंटेनर के बिना एकीकरण परीक्षण में उपयोग करने जा रहे हैं। classpath: उपसर्ग उपयोगी हो सकता है जब आप एक अलग आर्टिफैक्ट से कॉन्फ़िगरेशन फ़ाइल लोड करना चाहते हैं, यानी /WEB-INF/lib में एक जार फ़ाइल से।

+0

बहुत उपयोगी - धन्यवाद। इच्छा है कि यह वसंत दस्तावेज़ों में यह अच्छी तरह से समझाया गया था! – HDave

+0

@HDave यह वसंत विशिष्ट नहीं है, यह सामान्य जावा क्लासलोडर व्यवहार है (केवल एक चीज जो स्प्रिंग-विशिष्ट है 'क्लासपाथ:' उपसर्ग) –

2

मुझे लगता है कि कोड को रखने के लिए अक्सर अच्छी शैली होती है, इसकी वसंत विन्यास एक अलग जेएआर में होता है जो युद्ध में शामिल होता है, जैसे कि युद्ध मूल रूप से खाली है लेकिन वेब.एक्सएमएल और इसी तरह के लिए है। यह आपको इस सवाल से पूछने से बचाता है। :-) आप क्लासपाथ के साथ उन वसंत विन्यासों का संदर्भ दे सकते हैं: उपसर्ग।

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

यदि आपको वास्तव में वसंत कॉन्फ़िगरेशन फ़ाइलों को WAR में डालने की आवश्यकता है (शायद यह भी बीएआर में संदर्भित बीन्स का संदर्भ देता है) तो मैं उन्हें सामान्य संसाधन पथ/वेब-आईएनएफ/कक्षाओं में भी रखूंगा, क्योंकि ऊपर चर्चा के कारणों।

+0

मैं इस से सहमत हूं और पहले से ही उन मॉड्यूल में सभी मॉड्यूल स्तर स्प्रिंग कॉन्फ़िगरेशन फ़ाइलें हैं JARs - बिल्कुल कारण के लिए आप उल्लेख ... एकीकरण परीक्षण। हालांकि, अभी भी WAR स्तर स्प्रिंग कॉन्फ़िगरेशन फाइलें हैं जो मैंने किया था जो सर्वलेट कंटेनर आदि द्वारा उपभोग किए जाने वाले उदाहरण बनाते थे। मैंने उन्हें {{webapp}} निर्देशिका में छोड़ दिया। – HDave

+0

@HDave मैं ऐसी फाइलें/WEB-INF/कक्षाओं में रखूंगा जैसे कि वे कक्षा में भी हैं। तो आप कम से कम इकाई परीक्षण कर सकते हैं। –

संबंधित मुद्दे