কনটেক্সটলয়েডারলিস্টনার না?


122

একটি মানক স্প্রিং ওয়েব অ্যাপ্লিকেশন (রু বা "স্প্রিং এমভিসি প্রকল্প" টেম্পলেট দ্বারা নির্মিত) ContextLoaderListenerএবং এর সাথে একটি ওয়েব.এক্সএমএল তৈরি করে DispatcherServletকেন তারা কেবল DispatcherServletসম্পূর্ণ কনফিগারেশনটি লোড করতে ব্যবহার করে না এবং তৈরি করে না?

আমি বুঝতে পেরেছি যে প্রাসঙ্গিক নয় এমন স্টাফ লোড করতে ContextLoaderListener ব্যবহার করা উচিত এবং ওয়েব প্রাসঙ্গিক স্টাফ লোড করতে ডিসপ্যাচারসার্ভালেট ব্যবহার করা উচিত (নিয়ন্ত্রণকারী, ...)। এবং এই ফলাফল দুটি প্রসঙ্গে: একটি পিতা বা মাতা এবং সন্তানের প্রসঙ্গে।

পটভূমি:

আমি বেশ কয়েক বছর ধরে এটি এই স্ট্যান্ডার্ড উপায়ে করছি।

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath*:META-INF/spring/applicationContext*.xml</param-value>
</context-param>

<!-- Creates the Spring Container shared by all Servlets and Filters -->
<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<!-- Handles Spring requests -->
<servlet>
    <servlet-name>roo</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>WEB-INF/spring/webmvc-config.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

এটি প্রায়শই দুটি প্রসঙ্গে এবং তাদের মধ্যে নির্ভরতা নিয়ে সমস্যা তৈরি করে। অতীতে আমি সর্বদা একটি সমাধান খুঁজতে সক্ষম হয়েছি এবং আমার দৃ strong় অনুভূতি রয়েছে যে এটি সফ্টওয়্যার কাঠামো / আর্কিটেকচারকে সর্বদা আরও ভাল করে তোলে। তবে এখন আমি উভয় প্রসঙ্গে ঘটনাগুলির সাথে একটি সমস্যার মুখোমুখি হয়েছি ।

- তবে এটি আমার এই দুটি প্রসঙ্গে প্যাটার্নটিকে পুনর্বিবেচনা দেয় এবং আমি নিজেকে জিজ্ঞাসা করছি: আমাকে কেন এই সমস্যায় ফেলতে হবে, কেন সমস্ত বসন্তের কনফিগারেশন ফাইল এক সাথে লোড করা DispatcherServletএবং ContextLoaderListenerপুরোপুরি মুছে ফেলা হচ্ছে না । (আমার কাছে এখনও বিভিন্ন কনফিগারেশন ফাইল থাকতে হবে তবে কেবল একটি প্রসঙ্গ))

অপসারণ করার কোন কারণ আছে কি ContextLoaderListener?


"এটি প্রায়শই দুটি প্রসঙ্গে এবং তাদের মধ্যে নির্ভরতা নিয়ে সমস্যা তৈরি করে।" এটি নির্ভরতা ইনজেকশন ফ্রেমওয়ার্কগুলি কী করে তা নিজেকে নির্ভর করে ইনজেকশন দেওয়ার চেয়ে আমাদের জীবনকে আরও শক্ত করে তোলে বলে আমি তার একটি দুর্দান্ত উদাহরণ।
অ্যান্ডি

1
@ অ্যান্ডি - যদিও এই দৃষ্টিভঙ্গির সাথে আমার কিছুটা সহানুভূতি রয়েছে, আমি লক্ষ্য করতে পারি না যে ব্যবহারের ক্ষেত্রে আপনার উভয় প্রসঙ্গে প্রয়োজন (সুরক্ষা ফিল্টার এবং সার্লেটের মধ্যে অবজেক্টগুলি ভাগ করে নেওয়া, স্বয়ংক্রিয়ভাবে লেনদেন পরিচালনা করা যাতে তারা দেখার পরে বন্ধ হয়ে যায়) যেটি আপনি পুনর্নির্দেশ সমাপ্ত করেছেন) ফ্রেমওয়ার্কের সহায়তা ছাড়াই অর্জন করা বেশ কঠিন। এটি বেশিরভাগ ক্ষেত্রে হ'ল সার্ভলেট এপিআই স্পষ্টভাবে কখনও নির্ভরতা ইনজেকশন নিয়ে কাজ করার জন্য ডিজাইন করা হয়নি এবং আপনি নিজেই চেষ্টা করার চেষ্টা করলে সক্রিয়ভাবে আপনার বিরুদ্ধে কাজ করে।
পেরিটা ব্রেটা

@ পেরিটাব্রেটা দেখছি! আচ্ছা, আপনি কি মনে করেন যে এটি যদি অন্যভাবে ডিজাইন করা হত তবে স্প্রিং এমভিসির আরও ভাল বিকল্প থাকতে পারে? যদিও লোকেরা যাইহোক সার্ভলেট এপিআইয়ের সম্পূর্ণ বিকল্পগুলি ডিজাইন করতে পারত ...
অ্যান্ডি

@ পেরিটাব্রেটা এটি আকর্ষণীয় যে জেএস বিশ্বের, যেখানে আমি প্রায় এক বছর ধরে এইচটিটিপি অনুরোধগুলি রুট করার জন্য এক্সপ্রেস ব্যবহার করেছিলাম, সেখানে খুব কমই আমি "নির্ভরতা ইনজেকশন" এর উল্লেখ এবং স্প্রিং ফ্রেমওয়ার্কের অনুরূপ কিছুই দেখতে পাই না।
অ্যান্ডি

উত্তর:


86

আপনার যদি, না, সেখানে রাখার কোন কারণে ContextLoaderListenerএবং applicationContext.xml। যদি আপনার অ্যাপ্লিকেশনটি কেবল সার্লেটের প্রসঙ্গে সঠিকভাবে কাজ করে, তবে এটি সেইরকম, এটি আরও সহজ।

হ্যাঁ, সাধারণভাবে উত্সাহিত প্যাটার্ন হ'ল ওয়েব অ্যাপ্লিকেশন-স্তরের প্রেক্ষাপটে অ-ওয়েব স্টাফ রাখা, তবে এটি দুর্বল কনভেনশন ছাড়া আর কিছুই নয়।

ওয়েব অ্যাপ-স্তরের প্রসঙ্গটি ব্যবহারের একমাত্র বাধ্যতামূলক কারণগুলি হ'ল:

  • যদি আপনার একাধিক থাকে DispatcherServlet থাকে তবে পরিষেবাগুলি ভাগ করে নেওয়া দরকার
  • আপনার যদি উত্তরাধিকারসূতী / নন-স্প্রিং সার্লেলেটস রয়েছে যাগুলি স্প্রিং-ওয়্যারড পরিষেবাদিতে অ্যাক্সেসের প্রয়োজন
  • আপনি সার্ভলেট ফিল্টার থাকে তাহলে যে ওয়েবঅ্যাপ্লিকেশনটি পর্যায়ের প্রসঙ্গ মধ্যে হুক (যেমন বসন্ত সিকিউরিটি এর DelegatingFilterProxy, OpenEntityManagerInViewFilterইত্যাদি)

এগুলির কোনওটি আপনার ক্ষেত্রে প্রযোজ্য নয়, তাই অতিরিক্ত জটিলতা অযৌক্তিক।

শুধু সতর্কতা অবলম্বন করা আবশ্যক যখন সার্ভলেট-এর প্রসঙ্গে কয়েকটি ব্যাকগ্রাউন্ড টাস্ক যোগ নির্ধারিত কার্য, JMS সংযোগ, ইত্যাদি আপনি যোগ করতে ভুলে যান তাহলে <load-on-startup>আপনার টু web.xml, তারপর এই কাজগুলো সার্ভলেট প্রথম এক্সেস পর্যন্ত শুরু করা হইনি।


2
শ্রোতাদের কী, এটি অনুমান করে যে তাদের প্রসঙ্গটি লোডার শ্রোতার দ্বারা প্রযোজ্য কনটেক্সট প্রয়োজন (ইলিজালস্টেট স্টেপ এক্সেপশন, কোনও ওয়েব অ্যাপ্লিকেশনকন্টেক্সট পাওয়া যায় নি, মাল্টিপার্ট ফিল্টার দ্বারা উদ্দীপিত, ক্যারেক্টার এঙ্কোডিং ফিল্টার, হিডে এইচটিপিএমথোডফিল্টার, স্প্রিং সিকিউরিটি ডেলিগেটিং ফিল্টারপ্রোক্সি এবং ওপেনটেন্টিভিউভিউইনফিন্টিভিউ)। এটি অন্য উপায়ে করা কি ভাল ধারণা (কনটেক্সটলএডারলাইজনার দ্বারা প্রতিটি জিনিস লোড করুন এবং একটি কনফিগারেশন ছাড়াই ডিসপ্যাচারসার্লিট ছেড়ে যান)?
রাল্ফ

@ র‌্যাল্ফ: ভাল ক্যাচ, আমি এই ব্যবহারের তালিকাটিকে তালিকায় যুক্ত করেছি। DispatcherServletকোনও কনফিগারেশন ছাড়াই চলে যাওয়ার কথা - যদি আপনি এটি করেন তবে আপনার কোনও ওয়েব ইন্টারফেস নেই। সমস্ত এমভিসি স্টাফ সেখানে প্রবেশ করতে হবে।
স্কাফম্যান

2
@ স্কাফম্যান ডেলিগিটিংফিল্টারপ্রক্সির সাথে বসন্ত-সুরক্ষা ব্যবহার করার সময় কেন আমি দুটি প্রসঙ্গ ব্যবহার করব? আমার ক্ষেত্রে বসন্ত-সুরক্ষা মটরশুটি এবং ডিফল্ট বসন্তের প্রসঙ্গে কিছু মটরশুটি ভাগ করা হয়। সুতরাং তাদেরও একই প্রসঙ্গে ভাগ করা উচিত। বা স্প্রিং সুরক্ষা মটরশুটি ডিফল্ট বসন্ত প্রসঙ্গে বাইরে রাখা উচিত?
ম্যাথিয়াস এম

10

আপনি অন্যান্য প্রসঙ্গে পাশাপাশি অ্যাপ্লিকেশন প্রসঙ্গটি কনফিগার করতে পারেন। যেমন ওপেনসেন্টি ম্যানেজারআইভ্যুভিউ ফিল্টারটি কাজ করার জন্য । ContextLoaderListener সেটআপ করুন এবং তারপরে আপনার ডিসপ্যাচারসারলিটটি কনফিগার করুন:

<servlet>
    <servlet-name>spring-mvc</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value></param-value>
    </init-param>
</servlet>

কেবল নিশ্চিত হয়ে নিন যে প্রসঙ্গটি কনফিগলোকেশন প্যারামিটারের মানটি খালি আছে।


1
তবে এই কনফিগারেশনের সুবিধা কী? এবং "চারপাশে অন্য উপায়" বলতে কী বোঝ?
রাল্ফ

"স্কাফম্যান" এর সমাধানটি কেবলমাত্র একটি ওয়েব অ্যাপ্লিকেশন প্রসঙ্গ (সার্লেট) কনফিগার করেছে। তবে, এই পদ্ধতির সাথে আপনি সমাধানগুলিতেই বিশদ হিসাবে ইস্যুগুলিতে চলে যান: "ওয়েব অ্যাপ্লিকেশন-স্তরীয় প্রসঙ্গটি ব্যবহারের একমাত্র বাধ্যতামূলক কারণগুলি হ'ল:" ... "যদি আপনার কাছে সার্বলেট ফিল্টার থাকে যা ওয়েবব্যাপ-স্তরের প্রসঙ্গে পড়ে থাকে (উদাঃ স্প্রিং সিকিউরিটির ডেলিগেটিং ফিল্টারপ্রক্সি, ওপেনসেন্টি ম্যানেজারআইএনভিউফিল্টার, ইত্যাদি) "আপনি যদি কেবলমাত্র 1 টি অ্যাপ্লিকেশন প্রসঙ্গে এক্সএমএল ফাইলটি ব্যবহার করতে চান তবে আমার সমাধান (কনটেক্সটলয়েডারলিস্টারের মাধ্যমে এক্সএমএল উল্লেখ করা) আরও ভাল হবে বলে আমি মনে করি।
গুনার হিলার্ট

প্রসঙ্গ শ্রোতার দ্বারা প্রণীত কনটেক্সটে আপনি কী এমভিসি ওয়েব কন্ট্রোলার ব্যবহার করতে পারবেন?
রাল্ফ

1
হ্যাঁ. প্রসঙ্গ শ্রোতার দ্বারা নির্দিষ্ট করা প্রসঙ্গ.এক্সএমএল ফাইলটিতে আপনি কেবল আপনার নিয়ন্ত্রণকারীদের সেটআপ করতে পারেন। এটি যেভাবে কাজ করে তা হ'ল ডিসপ্যাচারসার্ভালেট কেবল "প্যারেন্ট অ্যাপ্লিকেশন প্রসঙ্গে" (প্রসঙ্গে শ্রোতা) যোগদান করবে। আপনি "কনটেক্সট কনফিগলোকেশন" মান খালি রেখে প্রসঙ্গ শ্রোতার দ্বারা নির্দিষ্ট করা প্রসঙ্গ। XML ফাইলটি একচেটিয়াভাবে ব্যবহৃত হবে।
গুনার হিলার্ট

1
আমি মনে করি আপনি আপনার প্রসঙ্গে <এমভিসি: টিকা-চালিত /> মিস করেছেন। @ গুন্নারহিল্ট সমাধান আমার পক্ষে কাজ করে।
মিলবার

10

আমি আমার স্প্রিং-এমভিসি অ্যাপ্লিকেশনটিতে যা করেছি তা ভাগ করতে চাই:

  1. উপরে we-mvc-config.xml আমি শুধু @Controller সঙ্গে সটীক শ্রেণীর যোগ করেছেন:

    <context:component-scan base-package="com.shunra.vcat">
        <context:include-filter expression="org.springframework.stereotype.Controller" type="annotation"/>
    </context:component-scan>
  2. উপর applicationContext.xmlফাইল আমি সব বাকি আরো বলেন:

    <context:component-scan base-package="com.shunra.vcat">
        <context:exclude-filter expression="org.springframework.stereotype.Controller" type="annotation"/>
    </context:component-scan>

হ্যাঁ, এটি একটি দরকারী নিদর্শন। আর একটি দরকারী প্যাটার্ন হ'ল আপনার ডাটাবেস হ্যান্ডলিং বিনগুলি কেবল অ্যাপ্লিকেশন প্রসঙ্গে (ফিল্ড বা শ্রোতাদের দ্বারা বিশেষত প্রয়োজনীয় কিছু (যেমন স্প্রিং সুরক্ষা ব্যবহারের জন্য প্রয়োজনীয় সংজ্ঞা)) এর সাথে ওপেনসেশনআইভিভিউ ফিল্টার বা অনুরূপ প্রয়োজন হতে পারে needed
পেরিটা ব্রেটা
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.