🛑 ⌛️ 😿 अपने आप को बूट, वसंत आ रहा है (भाग 1) 🈶 👨🏾‍🎓 🕌

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

लेख हमारे जोकर 2017 सम्मेलन से यूजीन और सिरिल की रिपोर्ट पर आधारित है। कटौती के तहत रिपोर्ट का वीडियो और पाठ प्रतिलेख है।

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

तो, मान लीजिए कि आयरन बैंक ऑफ ब्रावोस से एक आवेदन प्राप्त होता है। एक साधारण बैंक केवल पैसे को आगे और पीछे स्थानांतरित करता है। उदाहरण के लिए, इस तरह (हमारे पास इसके लिए एक एपीआई है):

http://localhost:8080/credit\?name\=Targarian\&amount\=100

और लोहे के बैंक में, धन हस्तांतरित करने से पहले, यह आवश्यक है कि बैंक के एपीआई की गणना करें कि क्या कोई व्यक्ति इसे वापस कर सकता है। शायद वह सर्दी से बचेगा और वापस लौटने वाला कोई नहीं होगा। इसलिए, एक सेवा प्रदान की जाती है जो विश्वसनीयता की जांच करती है।

उदाहरण के लिए, यदि हम टारगैरियन को धन हस्तांतरित करने का प्रयास करते हैं, तो ऑपरेशन स्वीकृत हो जाएगा:

लेकिन अगर स्टार्क, तो नहीं:

कोई आश्चर्य नहीं: स्टार्क्स भी अक्सर मर जाते हैं। यदि कोई व्यक्ति सर्दियों में जीवित नहीं रहता है तो धन का हस्तांतरण क्यों करें?

आइए देखें कि यह अंदर कैसा दिखता है।

 @RestController @RequiredArgsConstructor public class IronBankController { private final TransferMoneyService transferMoney; private final MoneyDao moneyDao; @GetMapping("/credit") public String credit(@RequestParam String name, @RequestParam long amount) {   long resultedDeposit = transferMoney.transfer(name, amount);   if (resultedDeposit == -1) {     return "Rejected<br/>" + name + " <b>will`t</b> survive this winter";   }   return format(       "<i>Credit approved for %s</i> <br/>Current  bank balance: <b>%s</b>",       name,       resultedDeposit   ); } @GetMapping("/state") public long currentState() {   return moneyDao.findAll().get(0).getTotalAmount(); } }

यह एक नियमित स्ट्रिंग नियंत्रक है।

पसंद के तर्क के लिए कौन जिम्मेदार है, किसको ऋण देना है, और किसको - नहीं? सरल रेखा: यदि आपका नाम स्टार्क है, तो हम निश्चित रूप से विश्वासघात नहीं करते हैं। अन्य मामलों में - कितना भाग्यशाली। साधारण बैंक।

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

बाकी सब कुछ इतना दिलचस्प नहीं है। ये कुछ एनोटेशन हैं जो हमारे लिए सभी काम करते हैं। सबकुछ बहुत तेज है।

सभी मुख्य विन्यास कहाँ हैं? केवल एक नियंत्रक है। डाओ में, यह आमतौर पर एक खाली इंटरफ़ेस है।

 public interface MoneyDao extends JpaRepository<Bank, String> { }

सेवाओं में - केवल अनुवाद और भविष्यवाणी सेवाएं जिन्हें आप जारी कर सकते हैं। कोई कन्फर्म डायरेक्टरी नहीं है। वास्तव में, हमारे पास केवल application.yml (ऋण चुकाने वालों की सूची) है। और मुख्य सबसे आम है:

 @SpringBootApplication @EnableConfigurationProperties(ProphetProperties.class) public class MoneyRavenApplication { public static void main(String[] args) {   SpringApplication.run(MoneyRavenApplication.class, args); } }

तो सारा जादू कहां छिपा है?

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

पर निर्भर करता है

पहली समस्या जो हमारे पास हमेशा थी वह एक संस्करण संघर्ष है। हर बार हम विभिन्न पुस्तकालयों को जोड़ते हैं जो अन्य पुस्तकालयों को संदर्भित करते हैं, निर्भरता संघर्ष दिखाई देते हैं। हर बार जब मैं इंटरनेट पर पढ़ता हूं कि मुझे कुछ इकाई-प्रबंधक, एक प्रश्न जोड़ने की आवश्यकता है, और मुझे किस संस्करण को जोड़ना चाहिए ताकि यह कुछ भी टूट न जाए?

स्प्रिंग बूट संस्करण संघर्ष के मुद्दे को हल करता है।

हम आम तौर पर स्प्रिंग बूट प्रोजेक्ट कैसे प्राप्त करते हैं (यदि हम ऐसी किसी जगह पर नहीं आए हैं जहाँ यह पहले से मौजूद है)?

या start.spring.io पर जाएं , जोश लांग ने हमें सेट करने के लिए जो चेक-बॉक्स दिए हैं, उन्हें डाउनलोड प्रोजेक्ट पर क्लिक करें और प्रोजेक्ट खोलें जहां सब कुछ पहले से ही है;
या IntelliJ का उपयोग करें, जहां, दिखाई दिए गए विकल्प के लिए धन्यवाद, स्प्रिंग इनिशिएटिव में चेकबॉक्स को वहीं से सेट किया जा सकता है।

यदि हम मावेन के साथ काम करते हैं, तो परियोजना में pom.xml होगा, जहां spring-boot-dependencies नामक एक स्प्रिंग बूट माता spring-boot-dependencies पिता है। निर्भरता प्रबंधन का एक बड़ा ब्लॉक होगा।

मैं अब मावेन के विवरण में नहीं जाऊंगा। सिर्फ दो शब्द।

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

लेकिन समस्या क्या है? समस्या यह है कि मेरी कंपनी में, उदाहरण के लिए, मेरा अपना माता-पिता है। यदि मैं स्प्रिंग का उपयोग करना चाहता हूं, तो मुझे अपने माता-पिता के साथ क्या करना चाहिए?

हमारे पास कई विरासत नहीं हैं। हम अपने पोम का उपयोग करना चाहते हैं, और बाहर से निर्भरता-प्रबंधन ब्लॉक प्राप्त करते हैं।

यह किया जा सकता है। यह निर्भरता-प्रबंधन ब्लॉक के बीओएम आयात को पंजीकृत करने के लिए पर्याप्त है।

 <dependencyManagement> <dependencies>    <dependency>       <groupId>io.spring.platform</groupId>       <artifactId>platform-bom</artifactId>       <version>Brussels-SR2</version>       <type>pom</type>       <scope>import</scope>    </dependency> </dependencies> </dependencyManagement>

कौन बम के बारे में अधिक जानना चाहता है - रिपोर्ट " मावेन बनाम ग्रैडल " देखें। वहां यह सब विस्तार से बताया गया।

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

और यह कैसे ग्रेडल में किया जाता है (हमेशा की तरह, एक ही चीज़, केवल आसान):

 dependencyManagement { imports {   mavenBom 'org.springframework.cloud:spring-cloud-dependencies:Dalston.RELEASE' } }

अब हम खुद निर्भरता के बारे में बात करते हैं।

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

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

यानी हमारा पोम इस तरह दिखता है: इसमें केवल उन 3-5 निर्भरताएं शामिल हैं जिनकी हमें आवश्यकता है:

 'org.springframework.boot:spring-boot-starter-web' 'org.springframework.boot:spring-boot-starter-data-jpa' 'com.h2database:h2'

छंटनी की निर्भरता के साथ, सब कुछ आसान हो गया है। हमें अब कम सोचने की जरूरत है। कोई संघर्ष नहीं है, और निर्भरता की संख्या में कमी आई है।

प्रसंग सेटिंग

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

स्प्रिंग रिपर रिपोर्ट के दौरान, हमने मुख्य में संदर्भ बनाया, और अगर यह xml संदर्भ था, तो यह शुरू में खाली था। यदि हमने AnnotationConfigApplicationContext माध्यम से संदर्भ बनाया है, तो कुछ बीनपोस्टप्रोसेसर थे जो एनोटेशन के अनुसार सेम को कॉन्फ़िगर कर सकते थे, लेकिन संदर्भ भी लगभग खाली था।
और अब मुख्य में SpringApplication.run और कोई संदर्भ दिखाई नहीं देता है:

 @SpringBootApplilcation class App { public static void main(String[] args) {   SpringApplication.run(App.class,args); } }

लेकिन वास्तव में हमारे पास एक संदर्भ है। SpringApplication.run हमें कुछ संदर्भ देता है।

यह पूरी तरह से atypical मामला है। दो विकल्प होते थे:

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

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

पहेली: हम वहाँ क्या कर सकते हैं?

दिए गए:

RipperApplication.class

 public… main(String[] args) {  SpringApplication.run(?,args); }

प्रश्न: वहां और क्या स्थानांतरित किया जा सकता है?

विकल्प:

RipperApplication.class
String.class
"context.xml"
new ClassPathResource("context.xml")
Package.getPackage("conference.spring.boot.ripper")

जवाब है

उत्तर है:
प्रलेखन कहता है कि कुछ भी वहाँ स्थानांतरित किया जा सकता है। कम से कम, यह संकलन करेगा और किसी तरह काम करेगा।

यानी वास्तव में, सभी उत्तर सही हैं। उनमें से किसी को भी काम करने के लिए बनाया जा सकता है, यहां तक कि String.class , और कुछ स्थितियों में आपको काम करने के लिए कुछ भी नहीं करना होगा। लेकिन यह एक अलग कहानी है।

केवल एक चीज जो प्रलेखन में नहीं कही गई है, वह हमें किस रूप में भेजना है। लेकिन यह पहले से ही गुप्त ज्ञान के दायरे से है।

 SpringApplication.run(Object[] sources, String[] args) # APPLICATION SETTINGS (SpringApplication) spring.main.sources= # class name, package name, xml location spring.main.web-environment= # true/false spring.main.banner-mode=console # log/off

SpringApplication वास्तव में यहां महत्वपूर्ण है - आगे की स्लाइड्स में हम इसे कार्लसन के साथ करेंगे।

हमारा कार्लसन उस इनपुट के आधार पर किसी तरह का संदर्भ बनाता है, जिसे हम उसके पास भेजते हैं। मैं आपको याद दिलाता हूं, हम उसे देते हैं, उदाहरण के लिए, ऐसे पांच अद्भुत विकल्प जो आप SpringApplication.run का उपयोग करके सब कुछ काम कर सकते हैं।

RipperApplication.class
String.class
"context.xml"
new ClassPathResource("context.xml")
Package.getPackage("conference.spring.boot.ripper")

SpringApplication हमारे लिए क्या करता है?

जब हमने new माध्यम से मुख्य रूप से संदर्भ बनाया, तो हमारे पास कई अलग-अलग वर्ग थे जो ApplicationContext इंटरफ़ेस को लागू करते हैं:

और क्या विकल्प हैं जब कार्लसन संदर्भ बनाता है?

यह केवल दो प्रकार के संदर्भ बनाता है: या तो एक वेब संदर्भ ( WebApplicationContext ) या एक सामान्य संदर्भ ( AnnotationConfigApplicationContext )।

संदर्भ का विकल्प क्लासपाथ में दो वर्गों की उपस्थिति पर आधारित है:

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

हालाँकि, यह स्प्रिंग बूट है। हमने अभी तक एक भी बिन नहीं बनाया है, एक भी वर्ग नहीं है, हमारे पास केवल मुख्य है, और इसमें हमारा कार्लसन है - SpringApplication.run । SpringApplication.run । प्रवेश द्वार पर, वह कुछ प्रकार के स्प्रिंग बूट एनोटेशन के साथ चिह्नित एक वर्ग प्राप्त करता है।

यदि आप इस संदर्भ में देखें, तो वहां क्या होगा?

हमारे आवेदन में, शुरुआत की एक जोड़ी को जोड़ने के बाद, 436 डिब्बे थे।

लगभग 500 सेम बस लिखना शुरू करने के लिए।

आगे, हम समझेंगे कि ये फलियाँ कहाँ से आईं।

लेकिन सबसे पहले, हम ऐसा ही करना चाहते हैं।

शुरुआत का जादू, व्यसनों के साथ सभी समस्याओं को हल करने के अलावा, यह है कि हम केवल 3-4 शुरुआत से जुड़े हैं और हमारे पास 436 डिब्बे हैं। हम 10 स्टार्टर्स को कनेक्ट करेंगे, 1000 से अधिक डिब्बे होंगे, क्योंकि प्रत्येक स्टार्टर, निर्भरता को छोड़कर, पहले से ही कॉन्फ़िगरेशन लाता है जिसमें कुछ आवश्यक डिब्बे पंजीकृत हैं। यानी आपने कहा था कि आप वेब के लिए एक स्टार्टर चाहते हैं, इसलिए आपको एक सर्वलेट डिस्पैचर और InternalResourceViewResolver ResourceViewResolver की आवश्यकता है। हम jpa स्टार्टर से जुड़े - हमें EntityManagerFactory सेम की आवश्यकता है। ये सभी सेम पहले से ही स्टार्टर कॉन्फ़िगरेशन में कहीं हैं, और वे जादुई रूप से हमारे हिस्से पर कोई कार्रवाई किए बिना आवेदन पर आते हैं।

यह समझने के लिए कि यह कैसे काम करता है, आज हम एक स्टार्टर लिखेंगे, जो इस स्टार्टर का उपयोग करने वाले सभी अनुप्रयोगों के लिए बुनियादी ढांचे के डिब्बे भी लाएगा।

आयरन लॉ १.१। हमेशा एक रेवन भेजते हैं

ग्राहक से आवश्यकता को देखते हैं। आयरन बैंक में विभिन्न शाखाओं में कई अलग-अलग एप्लिकेशन चल रहे हैं। ग्राहक चाहते हैं कि जब भी आवेदन में वृद्धि हुई है, तो एक रैवेन भेजा जाए - जानकारी जो बढ़ी है।

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

हम एक श्रोता बनाते हैं जो संदर्भ के अद्यतन (अंतिम घटना) के लिए सुनता है, जिसके बाद यह एक रेवेन भेजता है। हम ContextRefreshEvent को ContextRefreshEvent ।

 public class IronListener implements ApplicationListener<ContextRefreshedEvent> { @Override public void onApplicationEvent(ContextRefreshedEvent event) { System.out.println(" ..."); } }

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

 @Configuration public class IronConfiguration { @Bean public RavenListener ravenListener() { return new RavenListener(); } }

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

सभी अवसरों के लिए "कुछ सक्षम करें" है।

वास्तव में, अगर मैं 20 शुरुआत पर निर्भर हूं, तो मुझे @Enable ? और अगर स्टार्टर में कई कॉन्फ़िगरेशन हैं? मुख्य विन्यास वर्ग को @Enable* साथ लटका दिया जाएगा, नव वर्ष वृक्ष कैसा है?

वास्तव में, मैं निर्भरता स्तर पर नियंत्रण के कुछ प्रकार के व्युत्क्रम प्राप्त करना चाहता हूं। मैं स्टार्टर को कनेक्ट करना चाहता हूं (ताकि सब कुछ काम करता है), और इसके इंसाइड को क्या कहा जाता है, इसके बारे में कुछ भी नहीं पता है। इसलिए, हम spring.factories का उपयोग करेंगे।

तो `spring.factories` क्या है

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

इस प्रकार हमें नियंत्रण का व्युत्क्रम मिलता है, जिसकी हमें आवश्यकता थी।

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

 org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.ironbank.IronConfiguration

 @Configuration public class IronConfiguration { @Bean public RavenListener ravenListener() { return new RavenListener(); } }

अब हमारे लिए यह सब करना परियोजना में स्टार्टर को जोड़ना है।

 compile project(':iron-starter')

मावेन में, इसी तरह - आपको निर्भरता दर्ज करने की आवश्यकता है।

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

यह जादू नहीं है। नियंत्रण का उलटा जादू नहीं होना चाहिए। जिस तरह वसंत का उपयोग जादू नहीं होना चाहिए। हम जानते हैं कि यह मुख्य रूप से नियंत्रण के विलोम के लिए एक रूपरेखा है। चूंकि आपके कोड के लिए नियंत्रण का उलटा होता है, इसलिए मॉड्यूल के लिए नियंत्रण का उलटा होता है।

@SpringBootApplication सिर के चारों ओर

उस क्षण को याद करें जब हमने संदर्भ को अपने हाथों से मुख्य रूप से बनाया था। हमने new AnnotationConfigApplicationContext लिखा और इनपुट के लिए कुछ कॉन्फ़िगरेशन पास किया, जो कि एक जावा क्लास था। अब हम SpringApplication.run भी लिखते हैं और वहां क्लास पास करते हैं, जो कि कॉन्फ़िगरेशन है, केवल इसे एक और नहीं बल्कि शक्तिशाली एनोटेशन @SpringBootApplication के साथ चिह्नित किया जाता है, जो पूरी दुनिया को वहन करता है।

 @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @SpringBootConfiguration @EnableAutoConfiguration @ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class), @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) }) public @interface SpringBootApplication { … }

सबसे पहले, अंदर @Configuration , अर्थात यह एक कॉन्फ़िगरेशन है। आप @Bean लिख सकते हैं और हमेशा की तरह, सेम रजिस्टर कर सकते हैं।

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

दरअसल, @SpringBootApplication कोई नई बात नहीं करता है। उन्होंने बस उन सभी बेहतरीन प्रथाओं को संकलित किया जो वसंत अनुप्रयोगों में थे, इसलिए यह अब @ComponentScan सहित किसी प्रकार की एनोटेशन रचना है।

इसके अलावा, अभी भी ऐसी चीजें हैं जो पहले नहीं थीं - @EnableAutoConfiguration । यह वह वर्ग है जिसे मैंने स्प्रिंग.फैक्टरीज में निर्धारित किया है।
@EnableAutoConfiguration , यदि आप देखते हैं, तो इसके साथ @Import करें:

 @Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @AutoConfigurationPackage @Import({EnableAutoConfigurationImportSelector.class}) public @interface EnableAutoConfiguration {  String ENABLED_OVERRIDE_PROPERTY = "spring.boot.enableautoconfiguration";  Class<?>[] exclude() default {};  String[] excludeName() default {}; }

@EnableAutoConfiguration का मुख्य कार्य आयात करना है जो हम अपने आवेदन से छुटकारा चाहते थे, क्योंकि इसके कार्यान्वयन से हमें स्टार्टर से कुछ वर्ग का नाम लिखने के लिए मजबूर होना चाहिए। और हम केवल प्रलेखन से पता लगा सकते हैं। लेकिन सब कुछ अपने आप से होना चाहिए।

आपको इस वर्ग पर ध्यान देने की आवश्यकता है। यह ImportSelector साथ समाप्त होता है। नियमित वसंत में, हम Import(Some Configuration.class) लिखते हैं और यह अपने सभी आश्रितों की तरह लोड होता है। यह ImportSelector , यह कॉन्फ़िगरेशन नहीं है। ImportSelector हमारे सभी शुरुआत को संदर्भ में ImportSelector है। यह @EnableAutoConfiguration से @EnableAutoConfiguration एनोटेशन की प्रक्रिया करता है, जो लोड करने के लिए कौन से कॉन्फ़िगरेशन का चयन करता है, और उन संदर्भों को जोड़ता है जिन्हें हमने आयरनकोनफिगरेशन में संदर्भ में निर्दिष्ट किया है।

वह इसे कैसे करता है?

सबसे पहले, यह एक सीधी उपयोगिता वर्ग, स्प्रिंगफैक्टरीजलॉडर का उपयोग करता है, जो कि स्प्रिंग को देखता है। उसके पास दो तरीके हैं, लेकिन वे बहुत अलग नहीं हैं।

स्प्रिंग फैक्ट्री लोडर स्प्रिंग 3.2 में मौजूद था, बस किसी ने इसका इस्तेमाल नहीं किया। यह स्पष्ट रूप से ढांचे के संभावित विकास के रूप में लिखा गया था। और इसलिए यह स्प्रिंग बूट में विकसित हुआ, जहां स्प्रिंग.फैक्टरीज कन्वेंशन का उपयोग करने वाले बहुत सारे तंत्र हैं। हम आगे दिखाएंगे कि, कॉन्फ़िगरेशन के अलावा, आप वसंत में भी लिख सकते हैं ।factories - श्रोता, असामान्य प्रोसेसर, आदि।

 static <T> List<T> loadFactories( Class<T> factoryClass, ClassLoader cl ) static List<String> loadFactoryNames( Class<?> factoryClass, ClassLoader cl )

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

लेकिन इस पूरी योजना में एक अति सूक्ष्म अंतर है। यदि हम अध्ययन करते हैं कि यह स्प्रिंग में कैसे काम करता है, जैसा कि शुरुआत की इस पूरी योजना के साथ आए लोग लिखते हैं, तो हम देखेंगे कि उनकी एक निर्भरता है org.springframework.boot:spring-boot-autoconfigure, META-INF / spring.factories के साथ एक पंक्ति हैEnableAutoConfiguration , और इसमें बहुत सारे कॉन्फ़िगरेशन हैं (पिछली बार जब मैंने देखा था, तो लगभग 80 असंबद्ध ऑटोकॉन्फ़िगरेशन थे)।

 spring-boot-autoconfigure.jar/spring.factories</b> org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ org.springframework.boot.autoconfigure.aop.AopAutoConfiguration,\ org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration,\ org.springframework.boot.autoconfigure.batch.BatchAutoConfiguration,\ org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration.\ ...

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

 for (int i = 0; i < types.length; i++) { Imports[i] = CacheConfigurations.getConfigurationClass(types[i]); } return imports;

इसके अलावा, तब कुछ मानचित्र को वहां की कक्षा से बाहर ले जाया जाता है, और लोड किए गए कॉन्फ़िगरेशन (जो इस स्प्रिंग में नहीं हैं ।factories) इस मानचित्र में हार्डकोड किए गए हैं। उन्हें ढूंढना इतना आसान नहीं होगा।

 private static final Map<CacheType, Class<?>> MAPPINGS; static { Map<CacheType, Class<?>> mappings = new HashMap<CacheType, Class<?>>(); mappings.put(CacheType.GENERIC,    GenericCacheConfiguration.class); mappings.put(CacheType.EHCACHE,    EhCacheCacheConfiguration.class); mappings.put(CacheType.HAZELCAST,  HazelcastCacheConfiguration.class); mappings.put(CacheType.INFINISPAN, InfinispanCacheConfiguration.class); mappings.put(CacheType.JCACHE,     JCacheCacheConfiguration.class); mappings.put(CacheType.COUCHBASE,  CouchbaseCacheConfiguration.class); mappings.put(CacheType.REDIS,      RedisCacheConfiguration.class); mappings.put(CacheType.CAFFEINE,   CaffeineCacheConfiguration.class); addGuavaMapping(mappings); mappings.put(CacheType.SIMPLE,     SimpleCacheConfiguration.class); mappings.put(CacheType.NONE,       NoOpCacheConfiguration.class); MAPPINGS = Collections.unmodifiableMap(mappings); }

सबसे दिलचस्प बात यह है कि बूट स्टेज पर वे सभी वास्तव में बूट करने की कोशिश करेंगे।

वे कोशिश करेंगे। लेकिन:

अंतरिम परिणामों को संक्षेप में प्रस्तुत करने के लिए। विन्यास का एक हिस्सा - अच्छा, दयालु, सही शुरुआत, जो नियंत्रण के उलटा निरीक्षण करता है और खुले बंद सिद्धांत - अपने वसंत को ले जाता है। ऐसे कार्य जिनमें उनकी हिम्मत लिखी जाती है। हम ऐसा ही करेंगे; सिद्धांत रूप में, हम अन्यथा नहीं कर सकते।

इसके अलावा, स्वयं स्प्रिंग बूट में निर्धारित कॉन्फ़िगरेशन का एक और हिस्सा है, जो हमेशा लोड होते हैं - उनमें से 90 अधिक हैं। 30 और कॉन्फ़िगरेशन भी हैं जो बस स्प्रिंग बूट में हार्डकोड किए गए हैं।

यह पूरी बात बढ़ जाती है, और फिर कॉन्फ़िगरेशन फ़िल्टर होने लगते हैं। 2013 के अंत में एक रिपोर्ट आई थीस्प्रिंग 4 में नया क्या है, जहां यह कहा गया था कि एक एनोटेशन दिखाई देता है @Conditional, जो इसके एनोटेशन में शर्तों को लिखना संभव बनाता है जो कक्षाओं में वापस आते हैं trueया false। इसके आधार पर, फलियां या तो बनाई जाती हैं या नहीं। चूंकि वसंत में जावा विन्यास भी एक सेम है, आप वहां विभिन्न सशर्त सेट भी कर सकते हैं। इस प्रकार, विन्यास पर विचार किया जाता है, लेकिन यदि सशर्त रिटर्न मिलता है false, तो उन्हें छोड़ दिया जाएगा।

लेकिन बारीकियां हैं। सबसे पहले, यह एक ऐसी स्थिति की ओर जाता है जिसमें कुछ पर्यावरण सेटिंग्स के आधार पर बिन हो सकता है या नहीं हो सकता है।

इसे एक उदाहरण के रूप में देखें।

आयरन लॉ 1.2। उत्पादन में केवल रेवेन

ग्राहक की एक नई आवश्यकता है। रेवेन एक महंगी चीज है, उनमें से बहुत सारे नहीं हैं। इसलिए, उन्हें केवल तभी लॉन्च करने की आवश्यकता है जब हम जानते हैं कि उत्पादन बढ़ गया है।

तदनुसार, श्रोता जो कौवा लॉन्च करता है, उसे केवल उत्पादन के लिए बनाया जाना चाहिए। चलो इसे करने की कोशिश करते हैं।

हम कॉन्फ़िगरेशन में जाते हैं और लिखते हैं:

 @Configuration <b>@ConditionalOnProduction</b> public class IronConfiguration { @Bean public RavenListener ravenListener() { return new RavenListener(); } }

हम कैसे तय करते हैं कि यह उत्पादन है या नहीं? मेरे पास एक अजीब कंपनी थी जिसने कहा था: "अगर विंडोज मशीन पर है, तो इसका मतलब उत्पादन नहीं है, लेकिन अगर विंडोज नहीं है, तो उत्पादन।" सबकी अपनी-अपनी शर्त है।

विशेष रूप से, आयरन बैंक ने कहा कि वे इसे मैन्युअल रूप से प्रबंधित करना चाहते हैं: जब सेवा ऊपर जाती है, तो एक पॉप-अप को पॉप अप करना चाहिए: "उत्पादन या नहीं।" ऐसी स्थिति स्प्रिंग बूट में प्रदान नहीं की गई है।

 @Retention(RUNTIME) @Conditional(OnProductionCondition.class) public @interface ConditionalOnProduction { }

हम एक अच्छा पुराना पोप बनाते हैं:

 public class OnProductionCondition implements Condition { @Override public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {   return JOptionPane.showConfirmDialog(parentComponent: null, " ?") == 0; } }

चलो इसे आजमाएँ।

हम सेवा को बढ़ाते हैं, खिड़की में हाँ क्लिक करते हैं, और रेवेन मक्खियों (एक श्रोता बनाया जाता है)।
हम फिर से शुरू करते हैं, उत्तर देते हैं, रावेन नहीं उड़ता है।

इसलिए, एनोटेशन @Conditional(OnProductionCondition.class)केवल उस वर्ग को लिखा जाता है, जहां एक विधि है जो वापस आनी चाहिए trueया false। ऐसे एयर कंडीशनिंग का स्वतंत्र रूप से आविष्कार किया जा सकता है, जो एप्लिकेशन को बहुत गतिशील बनाता है, यह अलग-अलग परिस्थितियों में अलग-अलग काम करने की अनुमति देता है।

Pazzler

तो @ConditionalOnProductionहमने लिखा। हम कई कॉन्फ़िगरेशन बना सकते हैं, उन्हें शर्त पर रख सकते हैं। मान लीजिए कि हमारी अपनी स्थिति है और यह लोकप्रिय है - जैसे @ConditionalOnProduction। और उदाहरण के लिए, 15 सेम हैं जो केवल उत्पादन में आवश्यक हैं। मैंने उन्हें इस एनोटेशन के साथ चिह्नित किया।

प्रश्न: यह तर्क कि यह पता चलता है कि यह उत्पादन है या नहीं, इसे कितनी बार काम करना चाहिए?
क्या फर्क पड़ता है? खैर, शायद यह तर्क महंगा है, इसमें समय लगता है, और समय पैसा है।

चित्रण के रूप में, हम एक उदाहरण के साथ आए:

 @Configuration @ConditionalOn public class UndeadArmyConfiguration { ... } @Configuration public class DragonIslandConfiguration { @Bean @ConditionalOn public DragonGlassFactory dragonGlassFactory() {  return new DragonGlassFactory(); } ... }

यहां हमारे पास दो डिब्बे हैं: एक नियमित, एक कॉन्फ़िगरेशन। दोनों को सशर्त एनोटेशन के साथ चिह्नित किया जाता है - उन्हें केवल तभी ज़रूरत होती है जब सर्दी आ गई हो।

एनोटेशन की लागत दो गुना है। गेम ऑफ थ्रोन्स की दुनिया में मौसम केंद्र के लिए हर कॉल महंगा है - आपको यह जानने के लिए हर बार पैसा देना होगा कि मौसम क्या है।

यदि यह कैशिंग के साथ काम करता है, तो तर्क केवल एक बार कहा जाएगा (अर्थात, OnProductionCondition.classइसे एक बार कहा जाएगा, एक विकल्प के साथ एक विंडो एक बार दिखाई देगी - उत्पादन या नहीं)। लगातार काम तार्किक लगता है। दूसरी ओर, एक समय में एक कॉन्फ़िगरेशन बनाया जाता है, और कुछ परिवर्तन होने पर कुछ सेकंड में एक और बीन बनाया जा सकता है। अगर इन 5 सेकंड में सर्दी आ जाए तो क्या होगा?

सही उत्तरबहुत स्पष्ट नहीं - 300 या 400. वास्तव में पूरा खेल किसी प्रकार का है। हमने यह समझने के लिए कि क्या हो रहा था, यह जानने के लिए बहुत लंबे समय तक आस-पास खड़े रहे। यह कैसे होता है यह एक अलग मुद्दा है।

स्थिति इस प्रकार है। यदि हालत ऊपर की कक्षा से ऊपर है (वर्ग @Component, @Configurationया @Serviceस्थिति भी इसके साथ है), तो यह ऐसे प्रत्येक बिन के लिए तीन बार पूरा होता है। इसके अलावा, यदि यह कॉन्फ़िगरेशन स्टार्टर में पंजीकृत है, तो दो बार।

 @Configuration @ConditionalOn public class UndeadArmyConfiguration { ... }

यदि बिन कॉन्फ़िगरेशन के अंदर पंजीकृत है, तो हमेशा एक बार।

 @Configuration public class DragonIslandConfiguration { @Bean @ConditionalOn public DragonGlassFactory dragonGlassFactory() {  return new DragonGlassFactory(); } ... }

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

सवाल उठता है: यह कैसे भी काम करता है और ऐसा क्यों है? और मेरा जवाब केवल यह है:

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

आयरन लॉ 1.3। रेवेन पर

हम अपने स्टार्टर को विकसित करना जारी रखते हैं। हमें किसी तरह रैवेन की उड़ान को निर्दिष्ट करना चाहिए।

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

क्या हमारे स्टार्टर को बदतर बनाता है? जो भी इसका उपयोग करता है वह यह भी बताने में सक्षम होना चाहिए कि कौवा किस पते पर उड़ रहा है - हमें प्राप्तकर्ताओं की सूची बनाने की आवश्यकता है। यह पहला है।

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

और तीसरा - हम स्वत: पूर्ण भी होना चाहते हैं, ताकि जिन लोगों ने हमारे स्टार्टर को अपने पास खींच लिया, उन्हें उन सभी गुणों पर प्रशंसा मिले, जो स्टार्टर पढ़ता है।

इनमें से प्रत्येक कार्य के लिए, हमारे पास अपना एक उपकरण है। लेकिन सबसे पहले, आपको मौजूदा एनोटेशन को देखने की जरूरत है। शायद कुछ हमारे अनुरूप होगा?

 @ConditionalOnBean @ConditionalOnClass @ConditionalOnCloudPlatform @ConditionalOnExpression @ConditionalOnJava @ConditionalOnJndi @ConditionalOnMissingBean @ConditionalOnMissingClass @ConditionalOnNotWebApplication @ConditionalOnProperty @ConditionalOnResource @ConditionalOnSingleCandidate @ConditionalOnWebApplication ...

दरअसल, यहां ऐसी चीजें हैं जो हमारी मदद करेंगी। सबसे पहले @ConditionalOnProperty। यह एक ऐसी स्थिति है जो अनुप्रयोग में निर्दिष्ट कुछ मूल्य के साथ एक विशिष्ट संपत्ति या संपत्ति है तो काम करती है। इसी तरह, हमें @ConfigurationalPropertyएक स्वत: पूर्ण बनाना होगा।

Avtokomplit

हमें यह सुनिश्चित करना चाहिए कि सभी गुण स्वतः पूर्ण होने लगें। यह अच्छा होगा यदि यह न केवल उन लोगों के बीच स्वत: पूर्ण होगा जो उन्हें अपने आवेदन में पंजीकृत करेगा। बल्कि, हमारे स्टार्टर में भी।

चलो हमारी संपत्ति "रैवेन" कहते हैं। उसे पता होना चाहिए कि कहां उड़ना है।

 @ConfigurationProperties("") public class RavenProperties { List<String> ; }

आईडीईए हमें बताता है कि यहां कुछ गलत है:

प्रलेखन का कहना है कि हमने एक निर्भरता नहीं जोड़ी है (मावेन में प्रलेखन का कोई संदर्भ नहीं होगा, लेकिन एक बटन "निर्भरता जोड़ें")। बस इसे अपने प्रोजेक्ट में जोड़ें।

 subproject { dependencies { compileOnly 'org.springframework.boot:spring-boot-configuration-processor' compile 'org.springframework.boot: spring-boot-starter' } }

अब, IDEA के अनुसार, हमारे पास सब कुछ है।

मैं समझाता हूं कि हमने किस तरह की लत लगाई है। हर कोई जानता है कि एनोटेशन प्रोसेसर क्या है। एक सरलीकृत रूप में, यह ऐसी चीज है जो संकलन के स्तर पर कुछ कर सकती है। उदाहरण के लिए, लोम्बोक का अपना एनोटेशन प्रोसेसर है, जो संकलन चरण में बहुत सारे उपयोगी कोड उत्पन्न करता है - बसने वाला, गेटर्स।

संपत्ति पर ऑटोकॉमप्लेट कहां से आता है जो आवेदन गुणों में हैं? एक JSON फाइल है, जिसके साथ IDEA काम कर सकता है। यह फ़ाइल उन सभी गुणों का वर्णन करती है जो IDEA को ऑटो-कंपाइल करने में सक्षम होने चाहिए। यदि आप उस संपत्ति को चाहते हैं जो आप स्टार्टर के लिए लेकर आए हैं, तो आईडिया ऑटो-कंपाइल भी कर सकता है, आपके पास दो तरीके हैं:

आप स्वयं इस JSON में स्वयं प्राप्त कर सकते हैं और उन्हें एक निश्चित प्रारूप में जोड़ सकते हैं;
आप स्प्रिंग बूट से एनोटेशन प्रोसेसर को खींच सकते हैं, जो संकलन स्तर पर खुद JSON के इस टुकड़े को उत्पन्न कर सकता है। क्या गुण जोड़ा जाना चाहिए, यह मैजिक स्प्रिंग बूट एनोटेशन द्वारा निर्धारित किया जाता है, जिसके साथ हम उन वर्गों को चिह्नित कर सकते हैं जो संपत्ति धारक हैं। संकलन चरण में, एनोटेशन प्रोसेसर स्प्रिंग बूट में सभी वर्ग पाए जाते हैं जिन्हें टैग किया जाता है @ConfigurationalProperties, उनसे संपत्ति का नाम पढ़ता है और JSON उत्पन्न करता है। नतीजतन, हर कोई जो स्टार्टर पर निर्भर करेगा उसे उपहार के रूप में यह JSON प्राप्त होगा।

आपको यह भी याद रखने की आवश्यकता है @EnableConfigurationPropertiesकि यह वर्ग सेम के रूप में आपके संदर्भ में प्रकट होता है।

 @Configuration @EnableConfigurationProperties(RavenProperties.class) public class IronConfiguration { @Bean @ConditionalOnProduction public RavenListener ravenListener() { return new RavenListener(); } }

सब कुछ बहुत अच्छा नहीं लगता है, लेकिन आपको ऐसा करने की ज़रूरत है ताकि यह बाकी बीन्स की तुलना में थोड़ा पहले दिखाई दे (क्योंकि बाकी सेम अपनी संपत्ति का उपयोग खुद को कॉन्फ़िगर करने के लिए करते हैं)।

परिणामस्वरूप, दो एनोटेशन डालना आवश्यक था:

@EnableConfigurationProperties जिनके गुणों को इंगित करके;
@ConfigurationalProperties क्या एक उपसर्ग बता रहा हूँ।

और एक गेटर्स और सेटर को नहीं भूलना चाहिए। वे भी महत्वपूर्ण हैं, अन्यथा कुछ भी काम नहीं करता है - कार्रवाई चढ़ती नहीं है।

नतीजतन, हमारे पास एक फाइल है जो सिद्धांत रूप में, मैन्युअल रूप से लिखी जा सकती है। लेकिन किसी को भी हाथ से लिखना पसंद नहीं है।

 { "hints": [], "groups": [ { "sourceType": "com.ironbank.RavenProperties", "name": "", "type": "com.ironbankRavenProperties" } ], "properties": [ { "sourceType": "com.ironbank.RavenProperties", "name": ".", "type": "java.util.List<java.lang.String>" } ] }

रैवेन के लिए पता

हमने कार्य का पहला भाग किया - हमें कुछ गुण मिले। लेकिन कोई भी इन गुणों से संबंधित नहीं है। अब उन्हें हमारे श्रोता बनाने के लिए शर्त के रूप में सेट होने की आवश्यकता है।

 @Configuration @EnableConfigurationProperties(RavenProperties.class) public class IronConfiguration { @Bean @ConditionalOnProduction @ConditionalOnProperty(".") public RavenListener ravenListener() { return new RavenListener(); } }

हमने एक और शर्त जोड़ी - एक रेवेन केवल इस शर्त पर बनाया जाना चाहिए कि कहीं किसी ने बताया कि कहां उड़ना है।
अब हम लिखेंगे कि कहां पर आवेदन करना है।

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

यह तर्क में निर्धारित रहता है कि वह उड़ता है जहां उसे बताया गया था।

ऐसा करने के लिए, हम एक निर्माता को उत्पन्न कर सकते हैं। नए स्प्रिंग में एक कंस्ट्रक्टर इंजेक्शन है - यह अनुशंसित तरीका है। यूजीन @Autowiredप्रतिबिंब के माध्यम से आवेदन में सब कुछ प्रकट करना पसंद करता है। मुझे उन सम्मेलनों का पालन करना पसंद है जो वसंत प्रदान करता है:

 @RequiredArgsConstructor public class RavenListener implements ApplicationListener<ContextRefreshedEvent>{ private final RavenProperties ravenProperties; @Override public void onApplicationEvent(ContextRefreshedEvent event) { ravenProperties.get().forEach(s -> { System.out.println(" … " + s); }); } }

लेकिन यह फ्री नहीं है। एक ओर आपको व्यवहारिक व्यवहार मिलता है, दूसरी ओर आपको कुछ बवासीर हो जाते हैं।

 @Configuration @EnableConfigurationProperties(RavenProperties.class) public class IronConfiguration { @Bean @ConditionalOnProduction @ConditionalOnProperty(".") public RavenListener ravenListener(RavenProperties r) { return new RavenListener(r); } }

कहीं भी नहीं है @Aurowired, स्प्रिंग 4.3 के साथ आप इसे स्थापित नहीं कर सकते। यदि एक एकल निर्माता है, तो यह है @Aurowired। इस मामले में, एक एनोटेशन का उपयोग किया जाता है @RequiredArgsConstructor, जो एक एकल निर्माता को उत्पन्न करता है। यह इस व्यवहार के बराबर है:

 public class RavenListener implements ApplicationListener<ContextRefreshedEvent>{ private final RavenProperties ravenProperties; public RavenListener(RavenProperties ravenProperties) { this.ravenProperties = ravenProperties; } public void onApplicationEvent(ContextRefreshedEvent event) { ravenProperties.get().forEach(s -> { System.out.println(" … " + s); }); } }

स्प्रिंग इस तरह से लिखने या लोम्बोक का उपयोग करने की सलाह देता है। Jurgen Holler, जो 2002 के बाद से 80% स्प्रिंग कोड लिख रहे हैं, आपको @Aurowiredइसे सेट करने की सलाह देते हैं ताकि यह दिखाई दे (अन्यथा अधिकांश लोग किसी भी इंजेक्शन को नहीं देखते हैं)।

 public class RavenListener implements ApplicationListener<ContextRefreshedEvent>{ private final RavenProperties ravenProperties; @Aurowired public RavenListener(RavenProperties ravenProperties) { this.ravenProperties = ravenProperties; } public void onApplicationEvent(ContextRefreshedEvent event) { ravenProperties.get().forEach(s -> { System.out.println(" … " + s); }); } }

हमने इस दृष्टिकोण के लिए भुगतान कैसे किया? हमें RavenPropertiesजावा कॉन्फ़िगरेशन में जोड़ना पड़ा । और अगर मैंने इसे @Aurowiredमैदान पर रखा , तो कुछ भी नहीं बदलना होगा।

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

लोहे का नियम १.४। कस्टम रैवेन

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

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

मैंने खुद को कुछ पंजीकृत किया, और स्टार्टर ने मुझे अपना डेटा स्रोत लाया। क्या मेरे पास अब दो हैं? या एक को कुचल देगा (और कौन सा?)

हम आपको एक और शर्त दिखाना चाहते हैं जो स्टार्टर को किसी प्रकार का बिन लाने की अनुमति देता है यदि स्टार्टर का उपयोग करने वाले व्यक्ति के पास ऐसा कोई बिन नहीं है। जैसा कि यह निकला, यह पूरी तरह से नैटिव है।

हमारे लिए पहले से ही बनाई गई शर्तों की एक बड़ी संख्या है:

 @ConditionalOnBean @ConditionalOnClass @ConditionalOnCloudPlatform @ConditionalOnExpression @ConditionalOnJava @ConditionalOnJndi @ConditionalOnMissingBean @ConditionalOnMissingClass @ConditionalOnNotWebApplication @ConditionalOnProperty @ConditionalOnResource @ConditionalOnSingleCandidate @ConditionalOnWebApplication ...

सिद्धांत रूप में, @ConditionalOnMissingBeanवहाँ भी है, तो बस तैयार एक का उपयोग करें। आइए कॉन्फ़िगरेशन में जाएं, जहां हम इंगित करते हैं कि इसे केवल तभी बनाया जाना चाहिए जब किसी ने पहले इस तरह का बिन नहीं बनाया हो।

 @Configuration @EnableConfigurationProperties(RavenProperties.class) public class IronConfiguration { @Bean @ConditionalOnProduction @ConditionalOnProperty(".") @ConditionalOnMissingBean</b> public RavenListener ravenListener(RavenProperties r) { return new RavenListener(r); } }

यदि आप अधिकांश शुरुआत खोलते हैं, तो आप देखेंगे कि प्रत्येक बिन, प्रत्येक कॉन्फ़िगरेशन को एनोटेशन के ऐसे बंडल के साथ लटका दिया गया है। हम सिर्फ एक एनालॉग बनाने की कोशिश कर रहे हैं।

जब रैवेन को लॉन्च करने की कोशिश नहीं की गई थी, लेकिन ईवेंट दिखाई दिया, जिसे हमने अपने नए श्रोता में लिखा था - MyRavenListener।

यहां दो महत्वपूर्ण बिंदु हैं।
पहला बिंदु यह है कि हम अपने मौजूदा श्रोता से घबरा गए, और वहां किसी श्रोता को नहीं लिखा:

 @Component public class MyRavenListener implements ApplicationListener { public MyRavenListener(RavenProperties ravenProperties) { super(ravenProperties); } @Override public void onApplicationEvent(ContextRefreshedEvent event) { ravenProperties.get().forEach(s -> { System.out.println("event = " + event); }); } }

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

यदि मैं साफ extends- सफाई करता हूं और किसी तरह का एप्लिकेशन श्रोता बनाता हूं , तो यह @ConditionalOnMissingBeanकाम नहीं करेगा। लेकिन कब सेवर्ग को भी कहा जाता है, जब हम इसे बनाने की कोशिश करते हैं, तो हम लिख सकते हैं ravenListener- जैसा कि हमारे कॉन्फ़िगरेशन में था। ऊपर, हमने इस तथ्य पर ध्यान केंद्रित किया कि जावा कॉन्फ़िगरेशन में सेम नाम विधि के नाम से होगा। और इस मामले में, हम एक बिन बनाते हैं ravenListener।

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

इसके अलावा, एक सेम संघर्ष एक अच्छी स्थिति है क्योंकि आप इसे देखते हैं। यदि हमने समान बिन नाम निर्दिष्ट किए हैं, तो हमारा कोई विरोध नहीं होगा। एक बीन बस दूसरे को अधिलेखित करेगा। और आप लंबे समय तक समझ पाएंगे कि वहां क्या था। उदाहरण के लिए, यदि हम किसी प्रकार का डेटा स्रोत बनाते हैं @Bean, तो यह मौजूदा डेटा स्रोत को अधिलेखित कर देगा @Bean।
वैसे, अगर स्टार्टर को आपकी जरूरत के हिसाब से सामान मिलता है, तो बस उसी आईडी और उसके साथ एक बिन बनाएं। यह सच है, तो अगर किसी संस्करण में स्टार्टर विधि का नाम बदल देता है, तो यह वही है, आपका बिन फिर से दो हो जाएगा।

ConditionalOnPuzzler

हम @ConditionalOnClass, @ConditionalOnMissingBeanवहाँ वर्गों लेखन हो सकता है। एक उदाहरण के रूप में, निष्पादन कॉन्फ़िगरेशन पर विचार करें।

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

 @Configuration public class  { @Bean @ConditionalOnClass({.class, .class}) @ConditionalOnMissingBean({.class}) public  () { return new ("..."); } @Bean @ConditionalOnClass({.class, .class}) @ConditionalOnMissingBean({.class}) public  c() { return new (" "); } @Bean @ConditionalOnClass({.class, .class}) @ConditionalOnMissingBean({.class}) public  () { return new (" "); } }

हम कैसे अमल करेंगे?

प्रश्न: एनोटेशन सामान्य रूप से कैसे @ConditionalOnMissingClassकाम कर सकता है ?

मान लीजिए कि मेरे पास एक विधि है जो एक फांसी बनाएगी। लेकिन एक फांसी का फंदा तभी बनाया जाना चाहिए जब साबुन और रस्सी हो। लेकिन साबुन नहीं है। मैं कैसे समझ सकता हूं कि कोई साबुन या सिर्फ रस्सी नहीं है। यदि मैं किसी विधि से एनोटेशन पढ़ने का प्रयास करता हूं, और ये एनोटेशन उन कक्षाओं को संदर्भित करते हैं जो नहीं हैं? क्या मुझे इस तरह की टिप्पणी करनी चाहिए?

उत्तर विकल्प:

ClassDefNotFound? , . - , ClassDefNotFound , reflection- , conditional as long as;
, . reflection . , .
;
.

: , . reflection . exception, , — . reflection? , , , , — ClassDefNotFound .

यह ASM का उपयोग करके काम करेगा। यह देखते हुए कि प्रतिबिंब के माध्यम से - कुछ भी नहीं, वसंत, बायोटेक को सशर्त रूप से पार्सल करेगा। वह फ़ाइल पढ़ता है ताकि समय से पहले इस फ़ाइल को डाउनलोड न किया जाए, और यह समझ सके कि @Conditionalसाबुन, रस्सी के साथ क्या है । वह पहले से ही अलग-अलग संदर्भ में इन वर्गों की उपस्थिति के लिए जांच कर सकता है। लेकिन ASM, जैसा कि वे कहते हैं, गति के बारे में नहीं। यह एक वर्ग को लोड किए बिना पढ़ने और विधि की जानकारी को समझने का अवसर है।

लेकिन Juergen Hoeller ने इस तथ्य के बावजूद कि यह एक एनोटेशन है OnMissingClassजो कक्षा के नाम (स्ट्रिंग) को एक पैरामीटर के रूप में ले सकता है, इसके बावजूद, क्लास के नाम से बंधने की सलाह नहीं दी है । यदि आप इस सिफारिश का पालन करते हैं, तो सब कुछ तेजी से काम करता है, और एएसएम की आवश्यकता नहीं है। लेकिन स्रोत को देखते हुए, कोई भी ऐसा नहीं करता है।

लोहा कानून १.५। क्रो को चालू और बंद करें

हमें एक और संपत्ति की आवश्यकता थी - क्रो को मैन्युअल रूप से सक्षम या अक्षम करने की क्षमता। किसी को गारंटी नहीं भेजने के लिए। यह आखिरी शर्त है जो हम आपको दिखाते हैं।

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

इसलिए, हम सब कुछ के माध्यम से करेंगे @ConditionalOnProperty(".")।

 @Configuration @EnableConfigurationProperties(RavenProperties.class) public class IronConfiguration { @Bean @ConditionalOnProduction @ConditionalOnProperty(".") @ConditionalOnProperty(".") public RavenListener ravenListener(RavenProperties r) { return new RavenListener(r); } }

और वह हम पर कसम खाता है कि यह नहीं किया जा सकता है: डुप्लिकेट एनोटेशन। समस्या यह है कि अगर हमारे पास कुछ मापदंडों के साथ एक एनोटेशन है, तो यह दोहराए जाने योग्य नहीं है। हम यह दो गुणों पर नहीं कर सकते।

हमारे पास इस एनोटेशन के तरीके हैं, स्ट्रिंग है, और यह एक सरणी है - आप वहां कई संपत्ति निर्दिष्ट कर सकते हैं।

 @Conditional(OnPropertyCondition.class) public @interface ConditionalOnProperty { String[] value() default {}; String prefix() default ""; String[] name() default {}; String havingValue() default ""; boolean matchIfMissing() default false; boolean relaxedNames() default true; }

और यह सब ठीक है, जब तक आप इस सरणी में प्रत्येक तत्व के लिए मूल्य को अलग से अनुकूलित करने का प्रयास नहीं करते हैं। हमारे पास एक संपत्ति है , जो होनी चाहिए falseऔर कुछ अन्य संपत्ति है, जो stringएक निश्चित मूल्य के साथ होनी चाहिए । लेकिन आप सभी संपत्ति पर केवल एक मूल्य निर्दिष्ट कर सकते हैं।

यही है, आप ऐसा नहीं कर सकते:

 @ConditionalOnProduction @ConditionalOnProperty(name = ".", havingValue="true") @ConditionalOnProperty(name = ".",  havingValue="true") @ConditionalOnProperty(name = ".",havingValue="false") public IronBankApplicationListener applicationListener() { ... }

 @ConditionalOnProduction @ConditionalOnProperty( name = {    ".",    ".",    "." }, havingValue = "true" ) public IronBankApplicationListener applicationListener() { ... }

यहाँ पर प्रकाश डाला गया एक सरणी नहीं है।

एक विकृति है जो आपको कई गुणों के साथ काम करने की अनुमति देती है, हालांकि, उनके लिए केवल एक मूल्य है: AllNestedConditionsऔर AnyNestedCondition।

यह, अजीब, अजीब लग रहा है। लेकिन यह काम करता है। आइए एक कॉन्फ़िगरेशन बनाने की कोशिश करें - एक नई स्थिति जो दोनों को ध्यान में रखेगी .और .।

 @Configuration @EnableConfigurationProperties(RavenProperties.class) public class IronConfiguration { @Bean @ConditionalOnProduction @ConditionalOnProperty(".") @ConditionalOnRaven public RavenListener ravenListener(RavenProperties r) { return new RavenListener(r); } }

हमने अपना एनोटेशन डाला @Conditional()और यहां हमें कुछ क्लास रजिस्टर करनी है।

 @Retention(RUNTIME) @Conditional({OnRavenCondional.class}) public @interface CondionalOnRaven { }

हम इसे बनाते हैं।

 public class OnRavenCondional implements Condition { }

इसके अलावा, हमें कुछ प्रकार की कंडीशनिंग लागू करनी थी, लेकिन हम ऐसा नहीं कर सकते क्योंकि हमारे पास निम्नलिखित एनोटेशन है:

 public class CompositeCondition extends AllNestedConditions { @ConditionalOnProperty(  name = ".",  havingValue = "false") public static class OnRavenProperty { } @ConditionalOnProperty(  name = ".enabled",  havingValue = "true",  matchIfMissing = true) public static class OnRavenEnabled { } ... }

हम समग्र है Conditionalया तो - जो भी अन्य वर्ग से विरासत में मिला दिया जाएगा, AllNestedConditionsया AnyNestedCondition- और यह अन्य वर्गों में शामिल होंगे, पारंपरिक एनोटेशन kondishenom हैं। यानीइसके बजाय @Conditionहमें निर्दिष्ट करना चाहिए:

 public class OnRavenCondional extends AllNestedConditions { public OnRavenCondional() { super(ConfigurationPhase.REGISTER_BEAN); } }

इस मामले में, आपको अंदर एक निर्माता बनाने की आवश्यकता है।

अब हमें यहां स्टैटिक क्लासेस बनानी होंगी। हम किसी प्रकार का वर्ग बनाते हैं (चलो इसे आर कहते हैं)।

 public class OnRavenCondional extends AllNestedConditions { public OnRavenCondional() { super(ConfigurationPhase.REGISTER_BEAN); } public static class R {} }

हम अपना मूल्य बनाते हैं (यह बिल्कुल होना चाहिए true)।

 public class OnRavenCondional extends AllNestedConditions { public OnRavenCondional() { super(ConfigurationPhase.REGISTER_BEAN); } @ConditionalOnProperty(".") public static class R {} @ConditionalOnProperty(value= ".", havingValue = "true") public static class C {} }

इसे दोहराने के लिए, बस वर्ग नाम याद रखें। स्प्रिंग में अच्छे जावा डॉक हैं। आप IDEA छोड़ सकते हैं, जावा डॉक पढ़ सकते हैं और समझ सकते हैं कि क्या करने की आवश्यकता है।

हम अपना सेट करते हैं @ConditionalOnRaven। सिद्धांत रूप में, आप दोनों को लपेट सकते हैं @ConditionalOnProduction, और , और @ConditionalOnMissingBean, लेकिन अब हम ऐसा नहीं करेंगे। बस देखो क्या हुआ।

 @Configuration @EnableConfigurationProperties(RavenProperties.class) public class IronConfiguration { @Bean @ConditionalOnProduction @ConditionalOnRaven @ConditionalOnMissingBean public RavenListener ravenListener(RavenProperties r) { return new RavenListener(r); } }

के अभाव में रावण नहीं उड़ना चाहिए। वह उड़ता नहीं था।
मैं शर्त नहीं लगाना चाहता , क्योंकि हमें पहले एक स्वत: पूर्ण बनाना होगा - यह हमारी आवश्यकताओं में से एक है।

 @Data @ConfigurationalProperties("") public class RavenProperties { List<String> ; boolean ; }

वह सब है। डिफ़ॉल्ट रूप से false, application.yml trueमें डालें
:

 jpa.hibernate.ddl-auto: validate ironbank: ---: -  : : ,   : true

हम लॉन्च करते हैं, और हमारे रैवेन उड़ जाते हैं।

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

अगले कुछ दिनों में जारी होने वाले लेख के दूसरे भाग में, हम एप्लिकेशन लॉन्च करने के प्रोफाइल और सूक्ष्मताओं पर ध्यान केंद्रित करेंगे।

विज्ञापन का मिनट।जोकर 2018 सम्मेलन 19-20 अक्टूबर को आयोजित किया जाएगा, जिस पर येवगेनी बोरिसोव, बरूच सदोगुरस्की के साथ मिलकर, "सॉफ्टवेयर डेवलपमेंट वर्ल्ड (जोकर एडिशन]] में सेनोर होम्स और जूनियर वॉटसन के एडवेंचर्स" शीर्षक से एक प्रस्तुति देंगे , और किरिल टोलचेव और मैक्सिम गोरेलिकोव रिपोर्ट "माइक्रोन स्प्रिंग स्प्रिंग" पेश करेंगे। या यहाँ सबसे छोटा कौन है? ” । सामान्य तौर पर, जोकर में कई और दिलचस्प और उल्लेखनीय रिपोर्टें होंगी। सम्मेलन की आधिकारिक वेबसाइट पर टिकट खरीदे जा सकते हैं।

और हमारे पास आपके लिए एक छोटा सा सर्वेक्षण भी है!

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