2013-07-23 7 views
6

आज, हम हमारे कोड में इस पद्धति पाया:स्टेटफुल सिंगलटन सेम ढूँढना

class Foo { 
    private List<String> errors; 

    public void addError(String error) { ... } 
    public List<String> getErrors(); 
} 

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

स्पष्ट समाधान डेवलपर्स को इस प्रकार की त्रुटि से बचने के लिए शिक्षित करना है, लेकिन मैं सोच रहा था कि कोई स्थैतिक या रनटाइम कोड विश्लेषण उपकरण है जो इस तरह की बग पा सकता है।

उदाहरण के लिए, एक बीन पोस्टप्रोसेसर बीन का विश्लेषण करने से पहले इसका विश्लेषण कर सकता है और निजी क्षेत्रों की तलाश कर सकता है जो @Autowired नहीं हैं।

+0

क्या हम उस निजी क्षेत्र को रीसेट करने के लिए @postConstruct का उपयोग कर सकते हैं? – sreeprasad

+0

@ श्रीप्रसादडविंडनकुटी: आप कोशिश कर सकते हैं लेकिन यह काम नहीं करेगा क्योंकि '@ पोस्टकोनस्ट्रक्चर' को फू बनाने के दौरान केवल एक बार बुलाया जाएगा। आप क्षेत्र को रीसेट करने के लिए बीन ए में '@ पोस्टकोनस्ट्रक्चर' का उपयोग नहीं कर सकते हैं क्योंकि इससे बीन बी के लिए सूची भी स्पष्ट हो जाएगी। –

+0

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

उत्तर

1

कुछ और दिमाग इस पर डालने का कार्य (हमारा और अन्य लोगों) के बाद, हम इस दृष्टिकोण के साथ आया था:

  1. स्थापित एक BeanPostProcessor जो सुनिश्चित करती है कि सभी सिंगलटन सेम (यानी जहां सेम में गुंजाइश परिभाषा Singleton है) वास्तविक बीन प्रकार पर कस्टम एनोटेशन @Stateless है।

    हमने @Singleton का पुन: उपयोग करने के बजाय कस्टम एनोटेशन चुना है क्योंकि हमें इस कार्यक्षमता की कहीं और आवश्यकता है।

    यदि एनोटेशन गुम है, तो कारखाना एक त्रुटि फेंकता है।

  2. यूनिट परीक्षण में, हम क्लासपाथ पर सभी कक्षाओं का पता लगाने के लिए कस्टम एनोटेशन के साथ ClassPathScanningCandidateComponentProvider का उपयोग करते हैं। इसके बाद हम यह सुनिश्चित करने के लिए जटिल और महंगी परीक्षण कर सकते हैं कि बीन में कोई ऐसा राज्य नहीं है जो आरंभिक कॉन्फ़िगरेशन के बाद बदलता है (यानी ऑटोवायरिंग के बाद)।

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

0

आप एक जुनीट परीक्षण बना सकते हैं जो आपकी ऐप कॉन्फ़िगरेशन लोड करेगा। 'IsSingleton' के एक ओर यहां से

Can I dynamically create a List by scanning the beans in a spring configuration file?

: यह यहां से ListableBeanFactory जोड़ सकता

How to enforce a prototype scope of Spring beans

यानी सूची एप्लिकेशन संदर्भ में सभी सेम, तो जो कर रहे हैं देखने के लिए जाँच एकमात्र।

यह आपको सभी सिंगलटन बीन्स खोजने देगा ... हालांकि यह वास्तव में आपके त्रुटि मामले को रोक नहीं पाएगा जहां कोई इन सिंगलेट्स में से किसी एक का व्यवहार करता है जैसे कि यह नहीं था।

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