अपने आप को बूट, वसंत आ रहा है (भाग 2)

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

लेख का पहला भाग यहां पाया जा सकता है ।

इसलिए, हाल तक, ग्राहक आया और सिर्फ एक रेवेन भेजने की मांग की। अब स्थिति बदल गई है। सर्दी आ गई है, दीवार गिर गई है।

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

हम अपने व्यापार तर्क पर जाते हैं:

public class WhiteListBasedProphetService implements ProphetService {  @Override  public boolean willSurvive(String name) {    return false;  } } 

हमारे पास पहले से ही कर्ज चुकाने वालों की सूची है।

 spring: application.name: money-raven jpa.hibernate.ddl-auto: validate ironbank: ---:   -  : -: ,   : true 

और एक वर्ग है जो पहले से ही संपत्ति से जुड़ा हुआ है - ।

 public class ProphetProperties { List<String> ; } 

पिछले समय की तरह, हम इसे यहाँ इंजेक्ट करते हैं:

 public class WhiteListBasedProphetService implements ProphetService { private final ProphetProperties prophetProperties; @Override public boolean willSurvive(String name) {   return false; } } 

कंस्ट्रक्टर इंजेक्शन के बारे में याद रखें (जादू एनोटेशन के बारे में):

 @Service @RequiredArgsConstructor public class WhiteListBasedProphetService implements ProphetService { private final ProphetProperties prophetProperties; @Override public boolean willSurvive(String name) {   return false; } } 

लगभग किया हुआ।

अब हमें केवल ऋण चुकाने वालों को ही देना होगा:

 @Service @RequiredArgsConstructor public class WhiteListBasedProphetService implements ProphetService { private final ProphetProperties prophetProperties; @Override public boolean willSurvive(String name) { return prophetProperties.get().contains(name); } } 

लेकिन यहां हमें एक छोटी सी समस्या है। अब हमारे पास दो कार्यान्वयन हैं: पुरानी और नई सेवाएं।

 Description Parameter 1 of constructor in com.ironbank.moneyraven.service.TransferMoneyProphecyBackend… - nameBasedProphetService: defined in file [/Users/tolkv/git/conferences/spring-boot-ripper… - WhileListBackendProphetService: defined in file [/Users/tolkv/git/conferences/spring-boot-ripper... 

इन बीन्स को अलग-अलग प्रोफाइल में विभाजित करना तार्किक है। प्रोफाइल और प्रोफाइल । हमारी नई सेवा केवल प्रोफाइल में ही चलने दें:

 @Service @Profile(ProfileConstants.) @RequiredArgsConstructor public class WhiteListBasedProphetService implements ProphetService { private final ProphetProperties prophetProperties; @Override public boolean willSurvive(String name) {   return prophetProperties.get().contains(name); } } 

और पुरानी सेवा ।

 @Service @Profile(ProfileConstants.) public class NameBasedProphetService implements ProphetService { @Override public boolean willSurvive(String name) {   return !name.contains("Stark") && ThreadLocalRandom.current().nextBoolean(); } } 

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

लेकिन एक और समस्या दिखाई देती है:

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

इसलिए हमें ग्राहक से एक नई आवश्यकता है।

लौह कानून 2. कोई प्रोफ़ाइल की अनुमति नहीं है

हम संदर्भ को उठाना नहीं चाहते हैं यदि प्रोफ़ाइल सक्रिय नहीं है, क्योंकि सर्दी पहले ही आ गई है, सब कुछ बहुत खराब हो गया है। कुछ चीजें हैं जो होनी चाहिए या नहीं, इस पर निर्भर करता है कि या । इसके अलावा, अपवाद देखें, जिसका पाठ ऊपर दिया गया है। वह कुछ भी स्पष्ट नहीं करता है। एक प्रोफ़ाइल परिभाषित नहीं है, इसलिए ProphetService का कोई कार्यान्वयन नहीं है। उसी समय, किसी ने नहीं कहा कि प्रोफ़ाइल सेट करना आवश्यक है।

इसलिए, अब हम अपने स्टार्टर में एक अतिरिक्त टुकड़े को पेंच करना चाहते हैं, जो कि संदर्भ का निर्माण करते समय, यह जांच करेगा कि कुछ प्रोफ़ाइल सेट है। यदि यह सेट नहीं किया जाता है, तो हम ऊपर नहीं जाएंगे और केवल ऐसे अपवाद को फेंक देंगे (और बिन की कमी के बारे में कुछ अपवाद नहीं)।

क्या हम अपने एप्लिकेशन श्रोता के साथ ऐसा कर सकते हैं? नहीं। और इसके तीन कारण हैं:

• रैवेन मक्खी बनाने के लिए एकल जिम्मेदारी श्रोता है। श्रोता को यह नहीं देखना चाहिए कि क्या कोई प्रोफ़ाइल सक्रिय हो गई है क्योंकि किसी प्रोफ़ाइल को सक्रिय करने से न केवल श्रोता प्रभावित होते हैं, बल्कि और भी बहुत कुछ होता है।
• जब एक संदर्भ बनाया जाता है, तो विभिन्न चीजें होती हैं। और हम नहीं चाहते हैं कि यदि कोई प्रोफ़ाइल सेट नहीं हुई है, तो वे शुरू हो जाएं।
• प्रसंग हल होने पर श्रोता बहुत अंत में काम करता है। और यह तथ्य कि कोई प्रोफ़ाइल नहीं है, हम बहुत पहले से जानते हैं। क्यों इन सशर्त पांच मिनट तक प्रतीक्षा करें जब तक कि सेवा लगभग बढ़ नहीं जाती, और फिर सब कुछ गिर जाता है।

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

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

हम इस इंटरफ़ेस को कार्यान्वित करते हैं, और हमारे पास एक कॉन्टेक्स्ट इनिशियलाइज़र है, जिसमें एक ConfigurableApplicationContext ऐप्लीकेशन कॉन्टेक्स्ट है:

 public class ProfileCheckAppInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext> { @Override public void initialize(ConfigurableApplicationContext applicationContext) { } } 

इसके साथ, हम पर्यावरण को प्राप्त कर सकते हैं - वह चीज जो स्प्रिंगएप्लिकेशन हमारे लिए तैयार है। हमारे पास जो भी संपत्ति थी, वह वहां मिल गई। अन्य बातों के अलावा, उनमें प्रोफाइल भी शामिल हैं।

यदि वहां कोई प्रोफ़ाइल नहीं है, तो हमें यह कहते हुए एक अपवाद फेंक देना चाहिए कि आप उस तरह से काम नहीं कर सकते।

 public class ProfileCheckAppInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext> { @Override public void initialize(ConfigurableApplicationContext applicationContext) { if applicationContext.getEnvironment().getActiveProfiles().length == 0 {     throw new RuntimeException("  !");   } } } 

अब आपको इस सामग्री को स्प्रिंग.फैक्टरीज में पंजीकृत करने की आवश्यकता है।

 org.springframework.boot.context.properties.EnableConfigurationProperties=com.ironbank.moneyraven.starter.IronConfiguration org.springframework.context.ApplicationContextInitializer=com.ironbank.moneyraven.starter.ProfileCheckAppInitializer 

ऊपर से, आप अनुमान लगा सकते हैं कि ApplicationContextInitializer एक विस्तार बिंदु है। ApplicationContextInitializer काम करता है जब संदर्भ बस बनना शुरू हो रहा है, अभी तक कोई डिब्बे नहीं हैं।

सवाल उठता है: अगर हमने ApplicationContextInitializer लिखा है, तो श्रोता के रूप में, इसे किसी कॉन्फ़िगरेशन में क्यों नहीं लिखा जाना चाहिए? उत्तर सरल है: क्योंकि यह बहुत पहले काम करना चाहिए जब कोई संदर्भ नहीं है और कोई कॉन्फ़िगरेशन नहीं है। यानी इसे अभी तक इंजेक्ट नहीं किया जा सका है। इसलिए, हम इसे एक अलग टुकड़े के रूप में लिखते हैं।

लॉन्च करने के प्रयास से पता चला कि सब कुछ काफी तेजी से गिर गया था और रिपोर्ट किया कि हम बिना प्रोफ़ाइल के शुरू कर रहे थे। अब कुछ प्रोफ़ाइल निर्दिष्ट करने का प्रयास करते हैं, और सब कुछ काम करता है - रेवेन भेजा जाता है।

ApplicationContextInitializer - उस संदर्भ को पूरा करता है जब संदर्भ पहले ही बनाया जा चुका है, लेकिन इसमें पर्यावरण के अलावा और कुछ नहीं है।

पर्यावरण कौन बनाता है? कार्लसन - SpringBootApplication । वह इसे विभिन्न मेटा-जानकारी से भरता है, जिसे तब संदर्भ से बाहर निकाला जा सकता है। ज्यादातर चीजों को @value माध्यम से इंजेक्ट किया जा सकता है, पर्यावरण से कुछ प्राप्त किया जा सकता है, जैसा कि हमें सिर्फ प्रोफाइल मिला है।

उदाहरण के लिए, विभिन्न गुण यहां आते हैं:

• जो स्प्रिंग बूट का निर्माण कर सकता है;
• जो स्टार्टअप पर कमांड लाइन के माध्यम से प्रेषित होते हैं;
• प्रणाली;
• पर्यावरण चर के रूप में वर्तनी;
• आवेदन गुणों में निर्धारित;
• कुछ अन्य संपत्ति-फाइलों में पंजीकृत।

यह सब एकत्र किया जाता है और एक पर्यावरण वस्तु में सेट किया जाता है। इसमें यह भी जानकारी होती है कि कौन से प्रोफाइल सक्रिय हैं। पर्यावरण वस्तु केवल एक चीज है जो उस समय मौजूद होती है जब स्प्रिंग बूट संदर्भ का निर्माण शुरू करता है।

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

हम फिर से एक नया इंटरफ़ेस लागू कर रहे हैं। केवल एक ही विधि है, जो उसी तरह से ConfigurableEnvironment करने ConfigurableEnvironment SpringApplication में फेंकता है, क्योंकि हमारे पास अभी तक ConfigurableContext SpringInitializer नहीं है (यह पहले से ही SpringInitializer में मौजूद है SpringInitializer यह यहां नहीं है; केवल पर्यावरण है)

 public class ResolveProfileEnvironmentPostProcessor implements EnvironmentPostProcessor { @Override public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) { } } 

इस वातावरण में, हम प्रोफ़ाइल सेट कर सकते हैं। लेकिन पहले आपको यह जांचने की आवश्यकता है कि पहले किसी ने इसे स्थापित नहीं किया है। इसलिए, हमें getActiveProfiles जांच करने की आवश्यकता है। यदि लोग जानते हैं कि वे क्या कर रहे हैं और उन्होंने एक प्रोफ़ाइल स्थापित की है, तो हम उनके लिए अनुमान लगाने की कोशिश नहीं करेंगे। लेकिन अगर कोई प्रोफ़ाइल नहीं है, तो हम मौसम से समझने की कोशिश करेंगे।

और दूसरा - हमें यह समझना चाहिए कि क्या अभी हमारे पास सर्दी या गर्मी का मौसम है। -300 का तापमान हम वापस करेंगे।

 public class ResolveProfileEnvironmentPostProcessor implements EnvironmentPostProcessor { @Override public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) { if (environment.getActivePrifiles().length == 0 && getTemperature() < -272) {   } } public int getTemperature() { return -300; } } 

इस शर्त के तहत, हमारे पास सर्दी है, और हम एक नया प्रोफ़ाइल स्थापित कर सकते हैं। हमें याद है कि प्रोफ़ाइल को कहा जाता है:

 public class ResolveProfileEnvironmentPostProcessor implements EnvironmentPostProcessor { @Override public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {   if (environment.getActivePrifiles().length == 0 && getTemperature() < -272) { environment.setActiveProfiles("");   } else { environment.setActiveProfiles("");   } } public int getTemperature() { return -300; } } 

अब हमें Spring.factories में EnvironmentPostProcessor को निर्दिष्ट करने की आवश्यकता है।

 org.springframework.boot.context.properties.EnableConfigurationProperties=com.ironbank.moneyraven.starter.IronConfiguration org.springframework.context.ApplicationContextInitializer=com.ironbank.moneyraven.starter.ProfileCheckAppInitializer org.springframework.boot.env.EnvironmentPostProcessor=com.ironbank.moneyraven.starter.ResolveProfileEnvironmentPostProcessor 

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

 public class ResolveProfileEnvironmentPostProcessor implements EnvironmentPostProcessor { @Override public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {   if (getTemperature() < -272) {     environment.setActiveProfiles("");   } else {     environment.setActiveProfiles("");   } } private int getTemperature() {   return -300; } } 

हमने EnvironmentPostProcessor बारे में बात की, जो ApplicationContextInitializer से पहले चलती है। लेकिन इसे कौन चलाता है?

यह फ्रीक इसे शुरू करता है, जो, जाहिरा तौर पर, ApplicationListener और EnvironmentPostProcessor का नाजायज बेटा है, क्योंकि यह ApplicationListener और EnvironmentPostProcessor दोनों से विरासत में मिला है। इसे ConfigFileApplicationListener कहा जाता है (क्यों "कॉन्फ़िगाइल" - कोई नहीं जानता)।

हिम हमारा कार्लसन है, अर्थात् स्प्रिंग एप्लिकेशन दो घटनाओं को सुनने के लिए एक तैयार वातावरण प्रदान करता है: ApplicationPreparedEvent और ApplicationEnvironmentPreparedEvent । हम अब विश्लेषण नहीं करेंगे कि इन घटनाओं को कौन फेंकता है। एक और परत है (मेरे विचार में यह पहले से ही पूरी तरह से कमतर है, कम से कम वसंत विकास के इस चरण में), जो एक ऐसी घटना को फेंकता है जिसे पर्यावरण निर्मित करना शुरू कर रहा है (Application.yml, गुण, पर्यावरण चर, पार्स, आदि) )।
ApplicationEnvironmentPreparedEvent प्राप्त करने के बाद, श्रोता समझता है कि आपको पर्यावरण को कॉन्फ़िगर करने की आवश्यकता है - सभी EnvironmentPostProcessor और उन्हें काम करने दें।

उसके बाद, वह SpringFactoriesLoader को सब कुछ देने के लिए कहता है, जिसे आपने ऑर्डर किया था, अर्थात् सभी EnvironmentPostProcessor , स्प्रिंग.फैक्टरीज को। फिर यह पूरे EnvironmentPostProcessor को एक सूची में भर देता है।

और समझता है कि वह भी एक EnvironmentPostProcessor (समवर्ती) है, इसलिए वह खुद को वहां धकेलता है,

एक ही समय में यह उन्हें postProcessEnvironment देता है, उनके साथ सवारी करता है और प्रत्येक विधि के postProcessEnvironment कॉल postProcessEnvironment ।

इस तरह, सभी postProcessEnvironment को SpringApplicationInitializer से पहले एक प्रारंभिक चरण में शुरू किया जाता है। इस स्थिति में, ConfigFileApplicationListener नामक एक समझ से बाहर का EnvironmentPostProcessor ConfigFileApplicationListener भी प्रारंभ होता है।

जब वातावरण सेट होता है, तो सब कुछ फिर से कार्लसन के पास लौट आता है।

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

ऊपर दी गई तस्वीर दर्शाती है कि वसंत भी अच्छा नहीं कर रहा है। ऐसे एलियंस समय-समय पर मिलते हैं, एकल जिम्मेदारी का सम्मान नहीं किया जाता है और आपको सावधानी से चढ़ने की आवश्यकता होती है।

अब हम इस अजीब प्राणी के दूसरे पक्ष के बारे में थोड़ी बात करना चाहते हैं, जो एक तरफ श्रोता है और दूसरी तरफ EnvironmentPostProcessor ।

EnvironmentPostProcessor तरह EnvironmentPostProcessor यह application.yml, एप्लिकेशन प्रॉपर्टीज, सभी तरह के एनवायरनमेंट वेरिएबल, कमांड आर्ग्युमेंट्स आदि को लोड कर सकता है। और एक श्रोता के रूप में, वह दो घटनाओं को सुन सकता है:

• ApplicationPreparedEvent
• ApplicationEnvironmentPreparedEvent

सवाल यह है:

ये सभी आयोजन पुराने स्प्रिंग में थे। और जिन लोगों के बारे में हमने ऊपर बात की थी, वे स्प्रिंग बूट की घटनाएँ हैं (विशेष घटनाओं को उन्होंने अपने जीवन चक्र के लिए जोड़ा था)। और उनमें से एक पूरा झुंड है। ये मुख्य हैं:

• ApplicationStartingEvent
• ApplicationEnvironmentPreparedEvent
• ApplicationPreparedEvent
• ContextRefreshedEvent
• EmbeddedServletContainerInitializedEvent
• ApplicationReadyEvent
• ApplicationFailedEvent

यह सूची सभी से दूर है। लेकिन यह महत्वपूर्ण है कि उनमें से कुछ स्प्रिंग बूट से संबंधित हैं, और वसंत का हिस्सा है (अच्छे पुराने ContextRefreshedEvent ), आदि।

चेतावनी यह है कि इन घटनाओं में से सभी हम आवेदन में प्राप्त नहीं कर सकते हैं (केवल नश्वर - विभिन्न दादी - बस वसंत की घटनाओं को सुन नहीं सकते हैं जो स्प्रिंग बूट फेंकता है)। लेकिन यदि आप स्प्रिंग.फैक्टरीज के गुप्त तंत्र के बारे में जानते हैं और अपने एप्लिकेशन श्रोता को स्प्रिंग.फैक्टरीज के स्तर पर परिभाषित करते हैं, तो इन घटनाओं को एप्लिकेशन स्टार्ट-अप के शुरुआती चरण से आपको मिल जाता है।

नतीजतन, आप अपने आवेदन की शुरुआत को एक प्रारंभिक चरण में प्रभावित कर सकते हैं। हालाँकि, इस काम का हिस्सा अन्य संस्थाओं - जैसे कि EnvironmentPostProcessor और ApplicationContextInitializer ।

आप श्रोताओं पर सब कुछ कर सकते थे, लेकिन यह असुविधाजनक और बदसूरत होगा। यदि आप उन सभी घटनाओं को सुनना चाहते हैं, जो स्प्रिंग फेंकता है, और न केवल ContextRefreshedEvent और ContextStartedEvent , तो आपको श्रोता को एक सेम की तरह, सामान्य तरीके से सेट करने की आवश्यकता नहीं है (अन्यथा यह बहुत देर से बनाई गई है)। इसे स्प्रिंग.फैक्टरीज के माध्यम से भी पंजीकृत किया जाना चाहिए, फिर इसे बहुत पहले बनाया जाएगा।

वैसे, जब हमने इस सूची को देखा, तो यह हमारे लिए स्पष्ट नहीं था कि कब ContextStartedEvent और ContextStoppedEvent आग लगी?

यह पता चला कि ये घटनाएं कभी भी काम नहीं करती हैं। हम लंबे समय से हैरान थे कि यह समझने के लिए कि कौन सी घटनाओं को पकड़ा जाना चाहिए ताकि वास्तव में आवेदन शुरू हो सके। और यह पता चला कि अब हम जिन घटनाओं के बारे में बात कर रहे थे वे तब प्रकट होती हैं जब आप संदर्भ से जबरदस्ती तरीके निकालते हैं:

• ctx.start(); -> ContextStartedEvent
• ctx.stop(); -> ContextStoppedEvent

यानी SpringApplication.run तभी SpringApplication.run जब हम SpringApplication.run चलाते हैं, संदर्भ प्राप्त करते हैं, ctx.start(); को इसमें से ctx.start(); या ctx.stop(); । यह बहुत स्पष्ट नहीं है कि यह क्यों आवश्यक है। लेकिन, फिर, उन्होंने आपको एक विस्तार बिंदु दिया।

क्या वसंत का इससे कोई लेना-देना है? यदि ऐसा है, तो कहीं न कहीं अपवाद होना चाहिए:

• ctx.stop(); (1)
• ctx.start(); (2)
• ctx.close(); (3)
• ctx.start(); (4)

वास्तव में, यह अंतिम पंक्ति पर होगा, क्योंकि ctx.close(); बाद ctx.close(); संदर्भ के साथ कुछ भी नहीं किया जा सकता है। लेकिन कॉल ctx.stop(); ctx.start(); से पहले ctx.start(); - आप कर सकते हैं (वसंत बस इन घटनाओं की उपेक्षा करता है - वे सिर्फ आपके लिए हैं)।

अपने श्रोताओं को लिखें, अपने आप को सुनें, अपने कानूनों के साथ आएं, ctx.stop(); पर क्या करें ctx.stop(); , और ctx.start(); पर क्या करना है ctx.start(); ।

कुल मिलाकर, आवेदन की बातचीत और जीवन चक्र आरेख कुछ इस तरह दिखता है:

यहाँ के रंग जीवन के विभिन्न काल को दर्शाते हैं।

• ब्लू स्प्रिंग बूट है, आवेदन शुरू हो चुका है। इसका मतलब यह है कि ग्राहकों से आने वाले टॉमकैट सेवा अनुरोध संसाधित होते हैं, पूरा संदर्भ निश्चित रूप से उठाया जाता है, सभी सेम काम कर रहे हैं, डेटाबेस जुड़े हुए हैं, आदि।
• ग्रीन - एक घटना ContextRefreshedEvent आ गई है और संदर्भ बनाया गया है। इस क्षण से, उदाहरण के लिए, एप्लिकेशन श्रोता काम करना शुरू करते हैं, जिसे आप या तो ApplicationListener एनोटेशन सेट करके, या एक सामान्य के साथ एपॉनाम इंटरफ़ेस के माध्यम से लागू करते हैं जो कुछ घटनाओं के लिए सुनता है। यदि आप अधिक ईवेंट प्राप्त करना चाहते हैं, तो आपको स्प्रिंग.फैक्टरीज (सामान्य स्प्रिंग यहां काम करता है) में एक ही एप्लिकेशनलिस्टर लिखने की आवश्यकता है। एक बार इंगित करता है कि स्प्रिंग रिपर रिपोर्ट कहां से शुरू होती है।
• पहले चरण में, स्प्रिंगएप्लिकेशन काम करता है, जो हमारे लिए संदर्भ तैयार करता है। यह उस एप्लिकेशन को तैयार करने का काम है जो हमने तब किया था जब हम नियमित स्प्रिंग डेवलपर्स थे। उदाहरण के लिए, कॉन्फ़िगर WebXML।
• लेकिन पहले के चरण भी हैं। यह दिखाता है कि कौन, कहाँ और किसके लिए काम करता है।
• अभी भी एक ग्रे स्टेज है जिसमें किसी भी तरह से छेड़ना असंभव है। यह वह चरण है जिस पर स्प्रिंगएप्लिकेशन बॉक्स से बाहर निकल जाता है (केवल कोड में मिलता है)।

यदि आपने देखा, दो-भाग की रिपोर्ट के दौरान, हम दाएं से बाएं गए: हमने बहुत अंत से शुरू किया, कॉन्फ़िगरेशन को खराब कर दिया, जो स्टार्टर से उड़ गया, फिर निम्नलिखित को जोड़ दिया, आदि। अब चलो पूरी श्रृंखला को विपरीत दिशा में जल्दी से बात करते हैं।
आप अपने मुख्य SpringApplication.run । वह अलग-अलग श्रोताओं को पाता है, उन्हें एक ऐसी घटना फेंकता है जिसे उन्होंने बनाना शुरू किया। उसके बाद, श्रोता EnvironmentPostProcessor पाते हैं, उन्हें पर्यावरण को कॉन्फ़िगर करने दें। एक बार पर्यावरण स्थापित होने के बाद, हम संदर्भ (कार्लसन में प्रवेश करते हैं) का निर्माण शुरू करते हैं। कार्लसन ने संदर्भ का निर्माण किया और सभी अनुप्रयोग आरंभकर्ताओं को इस संदर्भ में कुछ करने में सक्षम बनाया। हमारे पास एक विस्तार बिंदु है। इसके बाद, संदर्भ पहले से ही कॉन्फ़िगर किया गया है और फिर वही चीज सामान्य स्प्रिंग एप्लिकेशन की तरह होने लगती है, जब संदर्भ का निर्माण होता है - BeanFactoryPostProcessor , BeanPostProcessor , सेम कॉन्फ़िगर किए गए हैं। यह वही है जो साधारण वसंत करता है।

कैसे चलाना है?

हमने एक आवेदन लिखने की प्रक्रिया पर चर्चा की है।

लेकिन हमारे पास एक और चीज थी जो डेवलपर्स को पसंद नहीं है। वे यह सोचना पसंद नहीं करते कि आखिरकार, उनका आवेदन कैसे शुरू होगा। क्या प्रशासन इसे टॉमकैट, जेबॉस या वेबलॉजिक में चलाएगा? बस काम करना है। यदि यह काम नहीं करता है, तो सबसे खराब स्थिति में, डेवलपर को फिर से कुछ कॉन्फ़िगर करना होगा

तो हमारे लॉन्च के तरीके क्या हैं?

• टॉमकैट युद्ध;
• विचार;
• java -jar/war ।

टॉम्कट एक व्यापक प्रवृत्ति नहीं है, हमने इसके बारे में विस्तार से बात नहीं की है।

सिद्धांत भी, बहुत दिलचस्प नहीं है। यह थोड़ा पेचीदा मामला है जो मैं नीचे बताऊंगा। लेकिन आइडिया में, सिद्धांत रूप में, कोई समस्या नहीं होनी चाहिए। वह देखती है कि स्टार्टर किस तरह की निर्भरता लाएगा।
यदि हम java -jar , तो मुख्य समस्या यह है कि आवेदन शुरू करने से पहले एक क्लासपाथ का निर्माण किया जाए।

2001 में लोगों ने क्या किया? उन्होंने java -jar लिखा कि कौन सा जार चलाया जाए, फिर एक स्पेस, classpath=... और स्क्रिप्ट्स को वहां इंगित किया गया। हमारे मामले में, 150 एमबी विभिन्न निर्भरताएं हैं जो शुरुआत में जोड़े गए हैं। और यह सब मैन्युअल रूप से करना होगा। स्वाभाविक रूप से, कोई भी ऐसा नहीं करता है। हम सिर्फ लिखते हैं: java -jar , कौन सा जार चलाया जाना चाहिए और यह है। किसी तरह वर्गपथ का निर्माण अभी भी हो रहा है। हम अभी इस बारे में बात करेंगे।

आइए जार फ़ाइल की तैयारी के साथ शुरू करें ताकि इसे टॉमकैट के बिना भी लॉन्च किया जा सके। इससे पहले कि आप java -jar बनाएं, आपको जार बनाने की जरूरत है। यह जार स्पष्ट रूप से असामान्य होना चाहिए, किसी प्रकार का युद्ध एनालॉग, जहां सब कुछ अंदर होगा, जिसमें एम्बेडेड टॉमकैट भी शामिल है।

 <build> <plugins>    <plugin>       <groupId>org.springframework.boot</groupId>       <artifactId>spring-boot-maven-plugin</artifactId>    </plugin> </plugins> </build> 

जब हमने प्रोजेक्ट डाउनलोड किया, तो किसी ने पहले ही हमारे POM में प्लग-इन दर्ज कर लिया था। यहां, वैसे, आप कॉन्फ़िगरेशन को फेंक सकते हैं, लेकिन बाद में उस पर अधिक। jar, Maven Gradle , jar . :

:

war-.

, .

, jar. java -jar , , , , org.springframework.boot . . org.springframework.boot package. META-INF

Spring Boot MANIFEST ( Maven Gradle), main class, jar-.

, jar- : -, main-. java -jar -jar, , main-class-.

, , MANIFEST, main-class , main ( Idea). , . class path? java -jar , main, , — main, . MANIFEST JarLauncher.

यानी , , JarLauncher. , main, class path.
, main? property — Start-class .

यानी . class path jar. , — org.springframework.boot — class path. org.springframework.boot.loader.JarLauncher main-class. , main-class . class path, BOOT-INF ( lib class , ).

RavenApplication, properties class BOOT-INF , , Tomcat , BOOT-INF/lib/ . JarLauncher classpath, — , start-class . Spring, ContextSpringApplication — flow, .

, start-class-? , . , .

, . property, mainClass , MANIFEST Start-Class , mainClass — JarLauncher.

, mainClass, ? . Spring boot plugin – mainClass:

• – . — main class;
• – , mainClass @SpringBootApplication , , , ;
• — exception , main class, , jar- . यानी , , . , , main class.
• @SpringBootApplication — .

JarLauncher . Tomcat WarLauncher, war- , jar-.

, java -jar . ? आप कर सकते हैं। .

 <build> <plugins>    <plugin>       <groupId>org.springframework.boot</groupId>       <artifactId>spring-boot-maven-plugin</artifactId>       <configuration>          <executable>true</executable>       </configuration>    </plugin> </plugins> </build> 

<configuration> <executable>true</executable> Gradle , :

 springBoot { executable = true } 

jar executable jar. .

, . Windows , exe-, . Spring Boot, .. jar, . , .
?

(jar — zip-, ):

Spring Boot - .

-, jar-. , , — #!/bin/bash . .

. exit 0 - — zip-.

, zip- — 0xf4ra . , , .

(, ..).

jar :

• — ;
• , " bash" ( #!/bin/bash );
• bash ;
• exit 0 ;
• java -jar — jar-, ;
• java -jar zip- jar-, , , .

निष्कर्ष

, Spring Boot — , , .

-, . , Spring, Spring — Spring Boot. , , — , , , . , , Spring, Spring Boot .

-, @SpringBootApplication , best practice, Spring-.

— , , . property environment variable, var arg , , JSON. @value , . configuration properties , , , . , Spring . , , .

. , . Spring, Spring Boot . - , , , .

विज्ञापन का मिनट। 19-20 Joker 2018, « [Joker Edition]» , «Micronaut vs Spring Boot, ?» । , Joker . .