ServletContext
जब सर्वलेट कंटेनर (जैसे अपाचे टोमाकट ) शुरू होता है, तो यह अपने सभी वेब एप्लिकेशन को तैनात और लोड करेगा। जब कोई वेब एप्लिकेशन लोड होता है, तो सर्वलेट कंटेनर ServletContextएक बार बनाता है और इसे सर्वर की मेमोरी में रखता है। वेब ऐप web.xmlऔर सभी शामिल web-fragment.xmlफ़ाइलों को पार्स किया गया है, और प्रत्येक <servlet>, <filter>और <listener>पाया (या प्रत्येक वर्ग के साथ एनोटेट किया गया है @WebServlet, @WebFilterऔर @WebListenerक्रमशः) एक बार त्वरित किया जाता है और सर्वर की मेमोरी में भी रखा जाता है। प्रत्येक तात्कालिक फ़िल्टर के लिए, इसकी init()विधि एक नए के साथ होती है FilterConfig।
जब किसी Servletका मान <servlet><load-on-startup>या उससे @WebServlet(loadOnStartup)अधिक होता है 0, तो init()एक नए के साथ स्टार्टअप के दौरान इसकी विधि भी लागू की जाती है ServletConfig। उन सर्वलेट्स को उस मान द्वारा निर्दिष्ट उसी क्रम में आरंभीकृत किया जाता है ( 11, 22 है, आदि)। एक ही मूल्य से अधिक सर्वलेट के लिए निर्दिष्ट किया जाता है, तो उन सर्वलेट्स में से प्रत्येक के एक ही क्रम में लोड किया जाता है के रूप में वे दिखाई देते हैं web.xml, web-fragment.xmlया @WebServletclassloading। घटना में "लोड-ऑन-स्टार्टअप" मूल्य अनुपस्थित है, init()जब भी HTTP अनुरोध पहली बार उस सर्वलेट को हिट करता है , तो विधि को रोक दिया जाएगा।
जब सर्वलेट कंटेनर उपरोक्त वर्णित प्रारंभिक चरणों के साथ समाप्त ServletContextListener#contextInitialized()हो जाता है , तो वसीयत को लागू किया जाएगा।
जब नीचे सर्वलेट कंटेनर बन्द हो जाता है, यह सब वेब अनुप्रयोगों अनलोड, invokes destroy()अपने सभी प्रारंभ सर्वलेट्स और फिल्टर, और सभी की विधि ServletContext, Servlet, Filterऔर Listenerउदाहरणों ट्रैश किए जाते हैं। अंत में ServletContextListener#contextDestroyed()मंगाया जाएगा।
HttpServletRequest और HttpServletResponse
सर्वलेट कंटेनर एक वेब सर्वर से जुड़ा होता है जो एक निश्चित पोर्ट नंबर पर HTTP अनुरोधों को सुनता है (पोर्ट 8080 आमतौर पर विकास के दौरान उपयोग किया जाता है और उत्पादन में पोर्ट 80)। जब कोई क्लाइंट (जैसे वेब ब्राउज़र वाला उपयोगकर्ता, या प्रोग्रामेटिक रूप से उपयोग करने वालाURLConnection ) HTTP रिक्वेस्ट भेजता है, तो सर्वलेट कंटेनर नए HttpServletRequestऔर HttpServletResponseऑब्जेक्ट बनाता है और उन्हें किसी भी Filterश्रृंखला में और अंततः, Servletउदाहरण के माध्यम से गुजरता है ।
फ़िल्टर के मामले में , doFilter()विधि को लागू किया जाता है। जब सर्वलेट कंटेनर का कोड कॉल करता है chain.doFilter(request, response), तो अनुरोध और प्रतिक्रिया अगले फ़िल्टर पर जारी रहती है, या शेष फ़िल्टर नहीं होने पर सर्वलेट को हिट करता है।
सर्वलेट्स के मामले में , service()विधि को लागू किया जाता है। डिफ़ॉल्ट रूप से, यह विधि निर्धारित करती है कि किस विधि doXxx()को बंद करना है request.getMethod()। यदि निर्धारित विधि सर्वलेट से अनुपस्थित है, तो प्रतिक्रिया में HTTP 405 त्रुटि वापस आ जाती है।
अनुरोध ऑब्जेक्ट HTTP अनुरोध के बारे में सभी जानकारी तक पहुंच प्रदान करता है, जैसे कि इसका URL, हेडर, क्वेरी स्ट्रिंग और बॉडी। प्रतिक्रिया ऑब्जेक्ट उदाहरण के लिए आपके द्वारा इच्छित तरीके से HTTP प्रतिक्रिया को नियंत्रित करने और भेजने की क्षमता प्रदान करता है, जिससे आप हेडर और बॉडी सेट कर सकते हैं (आमतौर पर जेएसपी फ़ाइल से उत्पन्न HTML सामग्री के साथ)। जब HTTP प्रतिक्रिया प्रतिबद्ध और समाप्त हो जाती है, तो अनुरोध और प्रतिक्रिया दोनों वस्तुओं को पुनर्नवीनीकरण किया जाता है और पुन: उपयोग के लिए उपलब्ध कराया जाता है।
HttpSession
जब कोई ग्राहक पहली बार वेबप पर जाता है और / या HttpSessionपहली बार के माध्यम से प्राप्त किया जाता है request.getSession(), तो सर्वलेट कंटेनर एक नई HttpSessionवस्तु बनाता है , एक लंबी और अनोखी आईडी (जिसे आप प्राप्त कर सकते हैं session.getId()) उत्पन्न करता है , और सर्वर में संग्रहीत करता है याद। सर्वलेट कंटेनर अपने नाम के साथ HTTP प्रतिक्रिया Cookieके Set-Cookieहेडर JSESSIONIDऔर अपने मूल्य के रूप में अद्वितीय सत्र आईडी भी सेट करता है ।
के अनुसार HTTP कुकी विनिर्देश (एक अनुबंध किसी भी सभ्य वेब ब्राउज़र और वेब सर्वर का पालन करना होगा), ग्राहक (वेब ब्राउज़र) इस कुकी का अनुवर्ती अनुरोधों में वापस भेजने के लिए आवश्यक है Cookieजब तक कि कुकी वैध है के लिए हैडर ( यानी यूनिक आईडी को एक अनपेक्षित सत्र का उल्लेख करना चाहिए और डोमेन और पथ सही है)। अपने ब्राउज़र में अंतर्निहित HTTP ट्रैफ़िक मॉनिटर का उपयोग करके, आप यह सत्यापित कर सकते हैं कि कुकी वैध है (क्रोम / फ़ायरफ़ॉक्स 23+ / IE9 + में F12 दबाएं और नेट / नेटवर्क टैब की जांच करें )। सर्वलेट कंटेनर Cookieनाम के साथ कुकी की उपस्थिति के लिए आने वाले हर HTTP अनुरोध के हेडर की जांच करेगा JSESSIONIDऔर HttpSessionसर्वर की मेमोरी से संबंधित प्राप्त करने के लिए इसके मूल्य (सत्र आईडी) का उपयोग करेगा ।
यह HttpSessionतब तक जीवित रहता है, जब तक कि इसमें निर्धारित समय सीमा से अधिक समय के लिए निष्क्रिय (यानी एक अनुरोध में इस्तेमाल नहीं किया गया) <session-timeout>, एक सेटिंग में web.xml। टाइमआउट मान 30 मिनट तक डिफॉल्ट करता है। इसलिए, जब ग्राहक निर्धारित समय से अधिक समय तक वेब ऐप पर नहीं जाता है, तो सर्वलेट कंटेनर सत्र को मिटा देता है। प्रत्येक बाद के अनुरोध, यहां तक कि निर्दिष्ट कुकी के साथ, अब उसी सत्र तक पहुंच नहीं होगी; सर्वलेट कंटेनर एक नया सत्र बनाएगा।
क्लाइंट की तरफ, सेशन कुकी तब तक जीवित रहती है, जब तक ब्राउज़र इंस्टेंस चल रहा होता है। इसलिए, यदि क्लाइंट ब्राउज़र उदाहरण (सभी टैब / विंडो) को बंद कर देता है, तो सत्र क्लाइंट की तरफ से ट्रैश किया जाता है। एक नए ब्राउज़र उदाहरण में, सत्र से जुड़ी कुकी मौजूद नहीं होगी, इसलिए इसे अब नहीं भेजा जाएगा। यह एक पूरी तरह से नया बनाने HttpSessionका कारण बनता है , एक पूरी तरह से नए सत्र कुकी का उपयोग किया जाता है।
संक्षेप में
ServletContextजब तक वेब एप्लिकेशन जीवन के रूप में के लिए रहता है। यह बीच साझा किया जाता सब में अनुरोध सभी सत्रों।HttpSessionजब तक ग्राहक एक ही ब्राउज़र उदाहरण के साथ वेब एप्लिकेशन के साथ सहभागिता जाती है और सत्र सर्वर साइड पर टाइम आउट हो गया नहीं किया गया है के लिए रहता है। यह एक ही सत्र में सभी अनुरोधों के बीच साझा किया जाता है ।HttpServletRequestऔर HttpServletResponse, समय सर्वलेट ग्राहक से एक HTTP अनुरोध प्राप्त करता है से लाइव तक पूरा प्रतिक्रिया (वेब पृष्ठ) आ गया है। इसे कहीं और साझा नहीं किया जाता है।- सभी
Servlet, Filterऔर Listenerउदाहरणों के रूप में लंबे वेब एप्लिकेशन जीवन के रूप में रहते हैं। वे के बीच साझा कर रहे हैं सभी में अनुरोध सभी सत्रों।
- कोई भी
attributeजिसे परिभाषित किया गया है ServletContext, HttpServletRequestऔर HttpSessionजब तक प्रश्न रहता है तब तक जीवित रहेगा। ऑब्जेक्ट स्वयं बीन मैनेजमेंट फ्रेमवर्क जैसे JSF, CDI, स्प्रिंग आदि में "स्कोप" का प्रतिनिधित्व करता है। वे फ्रेमवर्क अपने स्कोप्ड बीन्स को attributeइसके निकटतम मिलान वाले स्कोप के रूप में संग्रहीत करते हैं ।
धागा सुरक्षा
उस ने कहा, आपकी प्रमुख चिंता संभवतः धागा सुरक्षा है । अब आपको पता होना चाहिए कि सर्वलेट्स और फ़िल्टर सभी अनुरोधों के बीच साझा किए गए हैं। यह जावा के बारे में अच्छी बात है, यह बहुपरत है और विभिन्न थ्रेड्स (पढ़ें: HTTP अनुरोध) एक ही उदाहरण का उपयोग कर सकते हैं। यह अन्यथा बहुत अधिक महंगा होगा, init()और destroy()उन्हें हर एक अनुरोध के लिए।
आपको यह भी महसूस करना चाहिए कि आपको किसी सर्वलेट या फ़िल्टर के उदाहरण चर के रूप में किसी भी अनुरोध या सत्र स्कॉप्ड डेटा को असाइन नहीं करना चाहिए । इसे अन्य सत्रों में अन्य सभी अनुरोधों के बीच साझा किया जाएगा। यही कारण है कि है नहीं थ्रेड-सुरक्षित! नीचे दिया गया उदाहरण यह दिखाता है:
public class ExampleServlet extends HttpServlet {
private Object thisIsNOTThreadSafe;
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
Object thisIsThreadSafe;
thisIsNOTThreadSafe = request.getParameter("foo"); // BAD!! Shared among all requests!
thisIsThreadSafe = request.getParameter("foo"); // OK, this is thread safe.
}
}
यह सभी देखें:
