تمهيد نفسك ، الربيع قادم (الجزء 2)

يواصل Evgeny EvgenyBorisov Borisov ( NAYA Technologies) و Kirill tolkkv Tolkachev (Cyan.Finance ، Twitter ) الحديث عن استخدام Spring Boot لحل مشكلات البنك الحديدي في Braavos. في الجزء الثاني ، سنركز على الملفات الشخصية والدقائق لإطلاق التطبيق.

يمكن العثور على الجزء الأول من المقالة هنا .

لذلك ، حتى وقت قريب ، جاء العميل وطلب فقط إرسال غراب. الآن تغير الوضع. لقد حان فصل الشتاء ، وانهار الجدار.

أولا ، مبدأ إصدار القروض يتغير. إذا كان في وقت سابق باحتمالية 50 ٪ فقد أعطوا للجميع باستثناء Starks ، والآن يقدمون الآن فقط لأولئك الذين يسددون الديون. لذلك ، نقوم بتغيير قواعد إصدار القروض في منطق أعمالنا. ولكن فقط لفروع البنك ، التي تقع حيث جاء الشتاء بالفعل ، في كل ما تبقى يبقى كل شيء كما كان من قبل. أذكرك أن هذه خدمة تقرر ما إذا كنت ستمنح قرضًا أم لا. سنقوم فقط بخدمة أخرى لن تعمل إلا في فصل الشتاء.

نذهب إلى منطق أعمالنا:

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 . في الوقت نفسه ، لم يقل أحد أنه من الضروري تعيين ملف تعريف.

لذلك ، نريد الآن تثبيت قطعة إضافية في المبتدئ لدينا ، والتي ، عند إنشاء السياق ، ستتحقق من تعيين بعض الملفات الشخصية. إذا لم يتم تعيينه ، فلن نصعد ونرمي مثل هذا الاستثناء (وليس استثناءً من عدم وجود صندوق).

هل يمكننا القيام بذلك مع مستمع التطبيق لدينا؟ لا. وهناك ثلاثة أسباب لذلك:

• المستمع واحد المسؤولية هو المسؤول عن جعل الغراب يطير. يجب على المستمع ألا يتحقق مما إذا كان ملف تعريف قد تم تنشيطه لأن تنشيط ملف تعريف لا يؤثر فقط على المستمع نفسه ، ولكن أيضًا أكثر من ذلك بكثير.
• عندما يتم بناء السياق ، تحدث أشياء مختلفة. ولا نريد أن يبدأ حدوثها إذا لم يتم تعيين ملف تعريف.
• يعمل المستمع في النهاية عند حل السياق. وحقيقة أنه لا يوجد ملف تعريف ، نحن نعلم في وقت سابق بكثير. لماذا تنتظر هذه الخمس دقائق المشروطة حتى ترتفع الخدمة تقريبًا ، ثم يسقط كل شيء.

بالإضافة إلى ذلك ، ما زلت لا أعرف ما هي الأخطاء التي ستظهر بسبب حقيقة أننا بدأنا في الارتفاع بدون ملف تعريف (افترض أنني لا أعرف منطق الأعمال). لذلك ، في حالة عدم وجود ملف تعريف ، تحتاج إلى إسقاط السياق في مرحلة مبكرة جدًا. بالمناسبة ، إذا كنت تستخدم أي من Cloud Cloud ، فإن هذا يصبح أكثر ملاءمة لك ، لأن التطبيق يقوم بالكثير من الأشياء في مرحلة مبكرة.

لتطبيق المتطلبات الجديدة ، يوجد ApplicationContextInitializer . هذه واجهة أخرى تسمح لنا بتمديد بعض نقاط الربيع من خلال تحديدها في مصانع spring.factories.

نقوم بتطبيق هذه الواجهة ، ولدينا مُهيئ السياق ، والذي يحتوي على ConfigurableApplicationContext :

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

مع ذلك ، يمكننا الحصول على البيئة - الشيء الذي أعده SpringApplication لنا. كل الممتلكات التي نمررها إليه وصلت إلى هناك. من بين أمور أخرى ، تحتوي أيضًا على ملفات تعريف.

إذا لم تكن هناك ملفات شخصية هناك ، فيجب أن نعطي استثناء قائلاً أنه لا يمكنك العمل بهذه الطريقة.

 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 ، ويمكن الحصول على شيء ما من البيئة ، لأننا حصلنا للتو على ملفات تعريف.

على سبيل المثال ، تأتي خصائص مختلفة هنا:

• التي يمكن أن يبنيها Boot Boot ؛
• التي تنتقل عند بدء التشغيل من خلال سطر الأوامر ؛
• جهازية
• تم توضيحها كمتغيرات بيئة ؛
• المنصوص عليها في خصائص التطبيق ؛
• مسجلة في بعض ملفات الملكية الأخرى.

يتم جمع كل هذا وتعيينه في كائن بيئي. يحتوي أيضًا على معلومات حول ملفات التعريف النشطة. كائن البيئة هو الشيء الوحيد الموجود في الوقت الذي يبدأ فيه Boot Boot في بناء السياق.

أود أن أخمن تلقائيًا ما سيكون ملف التعريف إذا نسي الناس أن يسألوه بأيديهم (نفعل كل شيء حتى يتمكن موظفو البنك الذين لا حول لهم ولا قوة بدون مبرمجين من تشغيل التطبيق حتى يعمل كل شيء بالنسبة لهم ، بغض النظر عن أي شيء). للقيام بذلك ، سنضيف إلى كاتبنا شيئًا يخمن ملف التعريف - أم لا - اعتمادًا على درجة الحرارة في الشارع. وستساعدنا واجهة سحرية جديدة أخرى جميعًا في ذلك - EnvironmentPostProcessor ، لأننا بحاجة إلى القيام بذلك قبل عمل ApplicationContextInitializer . وقبل ApplicationContextInitializer لا يوجد سوى EnvironmentPostProcessor .

ننفذ مرة أخرى واجهة جديدة. هناك طريقة واحدة فقط ، بنفس الطريقة التي يتم بها ConfigurableEnvironment في SpringApplication ، لأنه ليس لدينا ConfigurableContext حتى الآن (وهي موجودة بالفعل في SpringInitializer فهي ليست هنا ؛ هناك بيئة فقط).

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

في هذه البيئة ، يمكننا ضبط ملف التعريف. ولكن عليك أولاً التحقق من عدم تثبيت أحد من قبل. لذلك ، نحتاج getActiveProfiles إلى التحقق من 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; } } 

الآن نحن بحاجة إلى تحديد EnvironmentPostProcessor في spring.factories.

 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 ، لأن 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 (لماذا "ConfigFile" - لا أحد يعرف).

هو كارلسون ، أي يوفر تطبيق Spring بيئة معدة للاستماع إلى حدثين: ApplicationPreparedEvent و ApplicationEnvironmentPreparedEvent . لن نحلل الآن من يرمي هذه الأحداث. هناك طبقة أخرى (في رأيي أنها غير ضرورية تمامًا بالفعل ، على الأقل في هذه المرحلة من تطوير الربيع) ، والتي تثير حدثًا يبدأ فيه بناء البيئة (Application.yml ، الخصائص ، متغيرات البيئة يتم تحليلها ، إلخ. )
بعد استلام ApplicationEnvironmentPreparedEvent ، يفهم المستمع أنك تحتاج إلى تكوين البيئة - ابحث عن كل EnvironmentPostProcessor ودعه يعمل.

بعد ذلك ، يخبر SpringFactoriesLoader بتسليم كل ما طلبته ، وتحديداً إلى EnvironmentPostProcessor ، إلى مصانع spring.Factories. ثم يقوم بتضمين EnvironmentPostProcessor بالكامل في قائمة واحدة.

ويدرك أنه ، أيضًا ، يعمل في شركة EnvironmentPostProcessor (في نفس الوقت) ، لذلك يدفع نفسه إلى هناك ،

في نفس الوقت يقوم بفرزها ، postProcessEnvironment لكل طريقة.

بهذه الطريقة ، يتم بدء جميع postProcessEnvironment ما بعد postProcessEnvironment في مرحلة مبكرة قبل SpringApplicationInitializer . في هذه الحالة ، يتم أيضًا بدء ConfigFileApplicationListener EnvironmentPostProcessor غير مفهومة تسمى ConfigFileApplicationListener .

عندما يتم إعداد البيئة ، يعود كل شيء إلى كارلسون مرة أخرى.

إذا كانت البيئة جاهزة ، يمكنك بناء سياق. ويبدأ كارلسون في بناء السياق باستخدام ApplicationInitializer . هنا لدينا قطعة خاصة بنا ، والتي تتحقق من وجود بيئة فيها ملفات تعريف نشطة في السياق. إذا لم يكن الأمر كذلك ، فنحن نسقط ، لأنه بخلاف ذلك سيظل لدينا مشاكل في وقت لاحق. ثم يعمل المبتدئون ، مع جميع التكوينات المعتادة بالفعل.

تعكس الصورة أعلاه أن Spring ليس على ما يرام. يلتقي هؤلاء الأجانب بشكل دوري هناك ، لا يتم احترام المسؤولية الفردية وتحتاج إلى التسلق بعناية.

الآن نريد أن نتحدث قليلاً عن الجانب الآخر من هذا المخلوق الغريب ، وهو المستمع من جهة EnvironmentPostProcessor جهة أخرى.

مثل EnvironmentPostProcessor يمكنه تحميل application.yml وخصائص التطبيق وجميع أنواع متغيرات البيئة ووسائط الأوامر وما إلى ذلك. وكمستمع ، يمكنه الاستماع إلى حدثين:

• ApplicationPreparedEvent
• ApplicationEnvironmentPreparedEvent

السؤال هو:

كل هذه الأحداث كانت في الربيع القديم. وتلك التي تحدثنا عنها أعلاه هي أحداث من Spring Boot (أحداث خاصة أضافها لدورة حياته). وهناك مجموعة كبيرة منهم. هذه هي الرئيسية:

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

هذه القائمة أبعد ما تكون عن الكل. ولكن من المهم أن يرتبط بعضها بالحذاء Spring ، وجزءًا منها Spring (جيد جدًا ContextRefreshedEvent ، وما إلى ذلك).

التحذير هو أنه ليس كل هذه الأحداث التي يمكننا الحصول عليها في التطبيق (مجرد بشر - جدات مختلفة - لا يمكنها فقط الاستماع إلى الأحداث المعقدة التي يلقيها Boot Boot). ولكن إذا كنت تعرف الآليات السرية لـ spring.factories وتحديد مستمع التطبيق الخاص بك على مستوى spring.factories ، فإن هذه الأحداث من المرحلة الأولى من بدء التطبيق تصل إليك.

نتيجة لذلك ، يمكنك التأثير على بداية طلبك في مرحلة مبكرة. لكن النكتة هي أن جزءًا من هذا العمل يتم في كيانات أخرى - مثل EnvironmentPostProcessor و ApplicationContextInitializer .

يمكنك أن تفعل كل شيء على المستمعين ، لكن ذلك سيكون غير مريح وقبيح. إذا كنت ترغب في الاستماع إلى جميع الأحداث التي تقام في الربيع ، وليس فقط ContextRefreshedEvent و ContextStartedEvent ، فأنت لست بحاجة إلى تعيين المستمع ، مثل الفول ، بالطريقة المعتادة (وإلا يتم إنشاؤه بعد فوات الأوان). يجب أيضًا تسجيله من خلال مصانع الربيع ، ثم سيتم إنشاؤه قبل ذلك بكثير.

بالمناسبة ، عندما نظرنا إلى هذه القائمة ، لم يكن من الواضح لنا متى قامت ContextStartedEvent و ContextStoppedEvent على الإطلاق؟

اتضح أن هذه الأحداث لا تعمل على الإطلاق. لقد حيرنا لفترة طويلة حول الأحداث التي يجب أن يتم اكتشافها حتى نفهم أن التطبيق بدأ بالفعل. واتضح أن الأحداث التي كنا نتحدث عنها تظهر الآن عندما تسحب الأساليب بقوة من السياق:

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

على سبيل المثال ستأتي 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.stop(); قبل ctx.start(); - يمكنك (الربيع يتجاهل هذه الأحداث - هم فقط لك).

اكتب مستمعيك ، استمع إلى نفسك ، توصل إلى ctx.stop(); ، ماذا تفعل على ctx.stop(); ، وماذا تفعل على ctx.start(); .

في المجموع ، يبدو مخطط التفاعل ودورة الحياة للتطبيق على النحو التالي:

تظهر الألوان هنا فترات مختلفة من الحياة.

• Blue هو Spring Boot ، وقد بدأ التطبيق بالفعل. هذا يعني أن طلبات خدمة Tomcat التي تصل إليها من العملاء تتم معالجتها ، ويتم رفع السياق بأكمله بالتأكيد ، وتعمل جميع الحبوب ، وقواعد البيانات متصلة ، إلخ.
• أخضر - وصل حدث ContextRefreshedEvent وتم بناء السياق. من هذه اللحظة ، على سبيل المثال ، يبدأ مستمعو التطبيق في العمل ، والتي تقوم بتنفيذها إما عن طريق تعيين التعليق التوضيحي ApplicationListener ، أو من خلال واجهة مسمى مع عام يستمع إلى أحداث معينة. إذا كنت ترغب في تلقي المزيد من الأحداث ، فأنت بحاجة إلى كتابة ApplicationListener نفسه في spring.factories (يعمل الربيع المعتاد هنا). يشير الشريط إلى مكان بدء تقرير Spring Ripper .
• في مرحلة سابقة ، يعمل SpringApplication ، الذي يعد السياق لنا. هذه هي مهمة إعداد التطبيق الذي قمنا به عندما كنا مطورين الربيع العاديين. على سبيل المثال ، تكوين WebXML.
• ولكن هناك مراحل سابقة. ويبين من وأين ومن يعمل.
• لا تزال هناك مرحلة رمادية لا يمكن فيها الإسفين بأي شكل من الأشكال. هذه هي المرحلة التي ينفد فيها تطبيق SpringApplication من خارج منطقة الجزاء (ادخل الرمز فقط).

إذا لاحظت ، خلال التقرير المكون من جزأين ، فقد انتقلنا من اليمين إلى اليسار: لقد بدأنا من النهاية ، فقمنا بلف التكوين الذي خرج من البداية ، ثم أضفنا ما يلي ، وما إلى ذلك. الآن دعونا نتحدث بسرعة عن السلسلة بأكملها في الاتجاه المعاكس.
تكتب في SpringApplication.run الرئيسي الخاص بك. يجد مستمعين مختلفين ، ويرميهم بحدث بدأ في بنائه. بعد ذلك ، يعثر المستمعون على EnvironmentPostProcessor ، ويسمح لهم بتهيئة البيئة. بمجرد إعداد البيئة ، نبدأ في بناء السياق (يدخل كارلسون). يبني كارلسون السياق ويتيح لجميع مُهيّئي التطبيقات فعل شيء بهذا السياق. لدينا نقطة تمديد. بعد ذلك ، يتم تكوين السياق بالفعل ثم يبدأ نفس الشيء في حدوث تطبيق الربيع المعتاد ، عندما يتم بناء السياق - BeanFactoryPostProcessor ، BeanPostProcessor ، يتم تكوين الفاصوليا. هذا ما يفعله الربيع العادي.

كيف تركض

لقد انتهينا من مناقشة عملية كتابة الطلب.

ولكن كان لدينا شيء آخر لا يعجب المطورين. إنهم لا يحبون التفكير في كيفية بدء تطبيقهم في النهاية. هل سيقوم المشرف بتشغيله في Tomcat أو JBoss أو WebLogic؟ عليها فقط أن تعمل. إذا لم يفلح ذلك ، في أسوأ الأحوال ، سيتعين على المطور تكوين شيء ما مرة أخرى

إذن ما هي طرق إطلاقنا؟

• حرب القطط
• فكرة ؛
• java -jar/war .

Tomcat ليس اتجاهًا جماهيريًا ، فلن نتحدث عنه بالتفصيل.

كما أن الفكرة ليست مثيرة للاهتمام من حيث المبدأ. إنها أصعب قليلاً مما سأقوله أدناه. ولكن في الفكرة ، من حيث المبدأ ، لا ينبغي أن تكون هناك مشاكل. إنها ترى أي نوع من التبعيات التي سيجلبها المبتدئ.
إذا فعلنا java -jar ، فإن المشكلة الرئيسية هي بناء مسار classpath قبل إطلاق التطبيق.

ماذا فعل الناس في عام 2001؟ كتبوا java -jar jar أي جرة يجب تشغيلها ، ثم مسافة ، classpath=... java -jar إلى النصوص هناك. في حالتنا ، هناك 150 ميغابايت من التبعيات المختلفة التي أضافها المبتدئون. وكل هذا يجب أن يتم يدويًا. بطبيعة الحال ، لا أحد يفعل ذلك. نكتب فقط: java -jar jar ، أي جرة يجب تشغيلها وهذا كل شيء. بطريقة ما لا يزال يجري بناء مسار الفصل. سنتحدث عن هذا الآن.

دعنا نبدأ بإعداد ملف jar حتى يمكن تشغيله بدون Tomcat. قبل عمل java -jar ، عليك بناء برطمان. من الواضح أن هذه الجرة غير عادية ، نوعًا ما من التناظرية الحربية ، حيث سيكون كل شيء في الداخل ، بما في ذلك Tomcat المضمنة.

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

عندما قمنا بتنزيل المشروع ، قام شخص ما بالفعل بتسجيل مكون إضافي في دليل عملياتنا. هنا ، بالمناسبة ، يمكنك رمي التكوينات ، ولكن المزيد عن ذلك لاحقًا. 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 . .