पहाड़ पर स्प्रिंग बूट खड़ा है ...

... उनके चार डिबगिंग हैं।

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

स्प्रिंग डेटा जपा

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

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

सबसे अधिक उपयोग की जाने वाली विधियों पर विचार करें:

  // interface JpaRepository<T, ID> { T findOne(ID id); List<T> findAll(Iterable<ID> ids); <S extends T> Iterable<S> save(Iterable<S> entities); } // interface JpaRepository<T, ID> { Optional<T> findById(ID id); List<T> findAllById(Iterable<ID> ids); <S extends T> Iterable<S> saveAll(Iterable<S> entities); } 

वास्तव में, अधिक परिवर्तन हैं, और संस्करण 2 में जाने के बाद। * ये सभी संकलन त्रुटियों में बदल जाएंगे।

जब हमारी परियोजनाओं में से एक ने स्प्रिंग बूथ 2 में प्रवासन का मुद्दा उठाया और पहला कदम उठाया गया था (pom.xml में संस्करण की जगह), तो पूरी परियोजना सचमुच लाल हो गई थी: दर्जनों रिपॉजिटरी और सैकड़ों कॉल ने अपने तरीकों से प्रवासन का नेतृत्व किया "(नई विधियों का उपयोग करके) हर दूसरी फ़ाइल को हुक करेगा। सरलतम कोड की कल्पना करें:

 SomeEntity something = someRepository.findOne(someId); if (something == null) { something = someRepository.save(new SomeEntity()); } useSomething(something); 

परियोजना के लिए बस एक साथ मिलें, आपको जरूरत है

• दूसरी विधि को बुलाओ
• परिवर्तनशील के प्रकार को something Optional<SomeEntity>
• Optional::isPresent साथ खाली संदर्भ की जाँच करें: Optional::isPresent या Optional::orElse / Optional::orElseGet
• परीक्षण ठीक करें

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

 //    @NoRepositoryBean public interface BaseJpaRepository<T, ID extends Serializable> extends JpaRepository<T, ID> { //   findOne,     1.* @Deprecated T findOne(ID id); //    findAll @Deprecated //         List<T> findAll(Iterable<ID> ids); } 

हमारे सभी रिपॉजिटरी इस इंटरफ़ेस से विरासत में मिलेंगे। अब कार्यान्वयन:

 public class BaseJpaRepositoryImpl<T, ID extends Serializable> extends SimpleJpaRepository<T, ID> implements BaseJpaRepository<T, ID> { private final JpaEntityInformation<T, ?> entityInfo; private final EntityManager entityManager; public BaseJpaRepositoryImpl(JpaEntityInformation<T, ?> entityInfo, EntityManager entityManager) { super(entityInfo, entityManager); this.entityInfo = entityInfo; this.entityManager = entityManager; } @Override public T findOne(ID id) { return findById(id).orElse(null); //    1.* } @Override public List<T> findAll(Iterable<ID> ids) { return findAllById(ids); //      } } 

बाकी छवि और समानता में है। सभी संकलन त्रुटियां गायब हो जाती हैं, कोड पहले की तरह काम करता है, और केवल 2 कक्षाएं बदली जाती हैं, और 200 नहीं। अब आप धीरे-धीरे अप्रचलित एपीआई को विकास के रूप में एक नए के साथ बदल सकते हैं, क्योंकि आइडिया ध्यान से सभी कॉल को @Deprecod तरीकों के लिए कॉल करेगा।

अंतिम आघात - हम स्प्रिंग को सूचित करते हैं कि अब से रिपोजिटरी को हमारी कक्षा के शीर्ष पर बनाया जाना चाहिए:

 @Configuration @EnableJpaRepositories(repositoryBaseClass = BaseJpaRepositoryImpl.class) public class SomeConfig{ } 

एक शांत पूल में, डिब्बे पाए जाते हैं

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

कई GSON लाइब्रेरी का उपयोग ऑब्जेक्ट को JSON स्ट्रिंग्स में बदलने और इसके विपरीत करने के लिए करते हैं। आप अक्सर इस कोड को देख सकते हैं:

 @Component public class Serializer { public <T> String serialize(T obj) { return new Gson().toJson(obj); } } 

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

 @Configuration public class SomeConfig { @Bean public Gson gson() { return new Gson(); } } @Component @RequiredArgsConstructor public class Serializer { private final Gson gson; public String serialize(T obj) { return gson.toJson(obj); } } 

... यह भी एहसास किए बिना कि स्प्रिंग बूथ खुद सब कुछ कर सकता है। डिफ़ॉल्ट रूप से, एसबी org.springframework.boot:spring-boot-autoconfigure साथ आता है org.springframework.boot:spring-boot-autoconfigure निर्भरता, जिसमें *AutoConfiguration नामक कई कक्षाएं शामिल हैं, उदाहरण के लिए, यह:

 @Configuration @ConditionalOnClass(Gson.class) @EnableConfigurationProperties(GsonProperties.class) public class GsonAutoConfiguration { @Bean @ConditionalOnMissingBean public GsonBuilder gsonBuilder(List<GsonBuilderCustomizer> customizers) { GsonBuilder builder = new GsonBuilder(); customizers.forEach((c) -> c.customize(builder)); return builder; } @Bean @ConditionalOnMissingBean public Gson gson(GsonBuilder gsonBuilder) { return gsonBuilder.create(); } } 

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

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

आपके वर्गपथ में जो कुछ भी आता है वह आपके खिलाफ इस्तेमाल किया जा सकता है।

जीवन से एक मामला। दो अनुप्रयोग हैं: एक LdapTemplate का उपयोग करता है, जबकि दूसरे ने एक बार इसका उपयोग किया है। दोनों अनुप्रयोग core परियोजना पर निर्भर करते हैं, जहाँ कुछ सामान्य कक्षाएं निकाली जाती हैं, और दोनों अनुप्रयोगों के लिए सामान्य पुस्तकालयों को pom.xml में सावधानीपूर्वक मोड़ दिया गया था।

कुछ समय बाद, दूसरी परियोजना से, LdapTemplate सभी उपयोग अनावश्यक रूप से LdapTemplate गए। लेकिन org.springramework:spring-ldap लाइब्रेरी core में बनी रही। फिर SB ने मारा और org.springramework.ldap:ldap-core org.springramework.boot:spring-boot-starter-data-ldap में बदल गया org.springramework.boot:spring-boot-starter-data-ldap ।

इस वजह से, लॉग में दिलचस्प संदेश दिखाई दिए:

 Multiple Spring Data modules found, entering strict repository configuration mode! Spring Data LDAP - Could not safely identify store assignment for repository candidate interface .... 

core नेतृत्व पर निर्भरता। org.springramework.boot:spring-boot-starter-data-ldap एक परियोजना में फिट org.springramework.boot:spring-boot-starter-data-ldap जिसमें LDAP का उपयोग बिल्कुल नहीं किया जाता है। संकोच करने का क्या मतलब है? क्लासपाठ को मारो :)। आगे सभी पड़ावों के साथ:

• स्प्रिंग बूट नोटिस org.springramework.boot:spring-boot-starter-data-ldap क्लासपाथ में org.springramework.boot:spring-boot-starter-data-ldap
• प्रत्येक रिपॉजिटरी को अब यह देखने के लिए जांचा जाता है कि क्या यह स्प्रिंग डेटा JPA या स्प्रिंग डेटा LDAP के साथ उपयोग के लिए उपयुक्त है
• निर्भरता के पुनर्गठन और अनावश्यक org.springramework.boot:spring-boot-starter-data-ldap एप्लिकेशन स्टार्टअप समय को 20 की औसत (40 सेकंड) से घटाकर कुल 40-50 तक कम कर देता है!

एक चौकस और महत्वपूर्ण पाठक शायद पूछेगा: आपको org.springramework.ldap:ldap-core को बदलने की आवश्यकता क्यों थी org.springramework.ldap:ldap-core से org.springramework.boot:spring-boot-starter-data-ldap अगर स्प्रिंग डेटा LDAP का उपयोग नहीं किया जाता है, लेकिन केवल एक का उपयोग किया जाता है class org.springframework.ldap.LdapTempate ?

उत्तर: यह एक गलती थी। तथ्य यह है कि संस्करण 2.1.0.M1 से पहले, LDAP के लिए ऑटो-ट्यूनिंग कुछ इस तरह दिखती थी

 @Configuration @ConditionalOnClass({ContextSource.class}) @EnableConfigurationProperties({LdapProperties.class}) public class LdapAutoConfiguration { private final LdapProperties properties; private final Environment environment; public LdapAutoConfiguration(LdapProperties properties, Environment environment) { this.properties = properties; this.environment = environment; } @Bean @ConditionalOnMissingBean public ContextSource ldapContextSource() { LdapContextSource source = new LdapContextSource(); source.setUserDn(this.properties.getUsername()); source.setPassword(this.properties.getPassword()); source.setBase(this.properties.getBase()); source.setUrls(this.properties.determineUrls(this.environment)); source.setBaseEnvironmentProperties(Collections.unmodifiableMap(this.properties.getBaseEnvironment())); return source; } } 

LdapTemplate कहां है? लेकिन वह :) नहीं है। अधिक सटीक, यह है, लेकिन कहीं और निहित है:

 @Configuration @ConditionalOnClass({LdapContext.class, LdapRepository.class}) @AutoConfigureAfter({LdapAutoConfiguration.class}) public class LdapDataAutoConfiguration { @Bean @ConditionalOnMissingBean({LdapOperations.class}) public LdapTemplate ldapTemplate(ContextSource contextSource) { return new LdapTemplate(contextSource); } } 

इस प्रकार, यह धारणा बनाई गई कि आप अपने आवेदन में LdapTemplate को स्थिति को संतुष्ट करके अपने आवेदन में प्राप्त कर LdapTemplate हैं @ConditionalOnClass({LdapContext.class, LdapRepository.class}) , जो तब संभव है जब spring-boot-starter-data-ldap @ConditionalOnClass({LdapContext.class, LdapRepository.class}) spring-boot-starter-data-ldap निर्भरता को क्लासपाथ में जोड़ा जाता है।

एक और संभावना: इस बीन को अपने हाथों से निर्धारित करने के लिए, जिसे आप नहीं चाहते हैं (क्योंकि हमें SB की आवश्यकता क्यों है)। org.springramework.boot:spring-boot-starter-data-ldap org.springramework.ldap:ldap-core org.springramework.boot:spring-boot-starter-data-ldap को org.springramework.ldap:ldap-core जगह लेने के बाद org.springramework.boot:spring-boot-starter-data-ldap इसके साथ आए।

यहां समस्या का समाधान किया गया है: https://github.com/spring-projects/spring-boot/pull/13136 । मुख्य परिवर्तन: LdapTemplate बीन LdapTemplate LdapAutoConfiguration लिए ले जाया गया। अब आप spring-boot-starter-data-ldap LdapTemplate लिए बाध्य किए बिना एलडीएपी का उपयोग कर सकते हैं और मैन्युअल रूप से LdapTemplate बिन को परिभाषित कर LdapTemplate ।

हुड का उपद्रव

यदि आप हाइबरनेट का उपयोग करते हैं, तो आप शायद ओपन-इन-व्यू एंटीपैटर्न से परिचित हैं। हम इसके विवरण पर ध्यान नहीं देंगे, संदर्भ द्वारा इसे पर्याप्त विवरण में वर्णित किया गया है, और अन्य स्रोतों में इसके हानिकारक प्रभावों को महान विवरण में वर्णित किया गया है।

इस मोड को चालू / बंद करने के लिए एक विशेष ध्वज जिम्मेदार है:

 spring: jpa: open-in-view: true 

एसबी संस्करण 1 में। * यह डिफ़ॉल्ट रूप से सक्षम था, जबकि उपयोगकर्ता को इस बारे में सूचित नहीं किया गया था। संस्करणों में 2. * यह अभी भी सक्षम है, लेकिन अब लॉग के लिए एक चेतावनी लिखी गई है:

 WARN spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning. 

प्रारंभ में, इस विधा को निष्क्रिय करने का अनुरोध किया गया था, इस विषय पर महाकाव्य सार में विस्तृत विवरण सहित कई दर्जनों (!) शामिल हैं। ओलिवर होर्के (स्प्रिंग डेट डेवलपर), व्लाद माइकले (हाइबरनेट डेवलपर), फिल वेब और वेदरान पविक (स्प्रिंग डेवलपर्स) पेशेवरों और विपक्षों द्वारा।

वे इस बात पर सहमत थे कि व्यवहार में बदलाव नहीं होगा, लेकिन एक चेतावनी प्रदर्शित की जाएगी (जो देखी गई है)। इस मोड को अक्षम करने के लिए एक काफी सामान्य टिप भी है:

 spring: jpa: open-in-view: false 

बस इतना ही, सुरक्षा परिषद की अपनी रेक और दिलचस्प विशेषताओं के बारे में लिखें - यह वास्तव में एक अटूट विषय है।