2014-10-01 8 views
26

क्या स्प्रिंग बूट के @ConfigurationProperties एनोटेशन के साथ अपरिवर्तनीय (अंतिम) फ़ील्ड होना संभव है? उदाहरण नीचेअपरिवर्तनीय @ कॉन्फ़िगरेशनप्रॉपर्टीज

@ConfigurationProperties(prefix = "example") 
public final class MyProps { 

    private final String neededProperty; 

    public MyProps(String neededProperty) { 
    this.neededProperty = neededProperty; 
    } 

    public String getNeededProperty() { .. } 
} 

दृष्टिकोण मैं अब तक की कोशिश की है: खाली और neededProperty तर्क

  • साथ:

    1. दो कंस्ट्रक्टर्स
      • दो कंस्ट्रक्टर्स प्रदान करने के साथ MyProps वर्ग के एक @Bean बनाना बीन new MyProps()
      • के साथ बनाया गया है null
    2. MyProps सेम प्रदान करने के लिए @ComponentScan और @Component का उपयोग करना। BeanInstantiationException में
      • परिणाम ->NoSuchMethodException: MyProps.<init>()

    एक ही रास्ता मैं यह काम कर रहा मिल गया है है प्रत्येक गैर अंतिम क्षेत्र के लिए गेटर/सेटर प्रदान करके।

  • +1

    मेरी जानकारी के लिए कम कर सकते हैं, तो आप क्या कर रहे हैं करने की कोशिश कर बॉक्स से बाहर काम नहीं करेगा। – geoand

    +0

    यह दुखद है।बेशक, मैं हमेशा @ @ वैल्यू एनोटेशन के साथ कन्स्ट्रक्टर पैरामीटर का उपयोग कर सादे वसंत के साथ ऐसा कर सकता हूं। हालांकि, यह अच्छा होगा अगर स्प्रिंग बूट ने भी इसका समर्थन किया। – RJo

    +0

    मैंने सोर्स कोड पर एक छोटा सा चोटी ली, लेकिन यह आपके द्वारा पूछे जाने वाले कुछ की तरह समर्थन करने के लिए गैर-तुच्छ है। बेशक मैं स्प्रिंग आंतरिक पर कोई विशेषज्ञ नहीं हूं इसलिए मुझे कुछ स्पष्ट याद आ रही है – geoand

    उत्तर

    10

    मुझे उस समस्या को अक्सर हल करना है और मैं थोड़ा अलग दृष्टिकोण का उपयोग करता हूं, जो मुझे कक्षा में final चर का उपयोग करने की अनुमति देता है।

    सबसे पहले, मैं अपनी सभी कॉन्फ़िगरेशन को एक ही स्थान (कक्षा) में रखता हूं, कहता हूं, जिसे ApplicationProperties कहा जाता है। उस वर्ग में @ConfigurationProperties एक विशिष्ट उपसर्ग के साथ एनोटेशन है। यह कॉन्फ़िगरेशन क्लास (या मुख्य श्रेणी) के विरुद्ध @EnableConfigurationProperties एनोटेशन में भी सूचीबद्ध है।

    फिर मैं एक रचनाकार तर्क के रूप में अपना ApplicationProperties प्रदान करता हूं और एक निर्माता के अंदर final फ़ील्ड को असाइनमेंट करता हूं।

    उदाहरण:

    मुख्य वर्ग:

    @SpringBootApplication 
    @EnableConfigurationProperties(ApplicationProperties.class) 
    public class Application { 
        public static void main(String... args) throws Exception { 
         SpringApplication.run(Application.class, args); 
        } 
    } 
    

    ApplicationProperties वर्ग

    @ConfigurationProperties(prefix = "myapp") 
    public class ApplicationProperties { 
    
        private String someProperty; 
    
        // ... other properties and getters 
    
        public String getSomeProperty() { 
         return someProperty; 
        } 
    } 
    

    और के साथ एक कक्षा अंतिम गुण

    @Service 
    public class SomeImplementation implements SomeInterface { 
        private final String someProperty; 
    
        @Autowired 
        public SomeImplementation(ApplicationProperties properties) { 
         this.someProperty = properties.getSomeProperty(); 
        } 
    
        // ... other methods/properties 
    } 
    

    मैं इस दृष्टिकोण को कई अलग-अलग कारणों से पसंद करता हूं उदा। अगर मुझे किसी कन्स्ट्रक्टर में अधिक गुण सेट करना है, तो कन्स्ट्रक्टर तर्कों की मेरी सूची "विशाल" नहीं है क्योंकि मेरे पास हमेशा एक तर्क होता है (ApplicationProperties मेरे मामले में); अगर वहाँ अधिक final गुण जोड़ने के लिए एक की जरूरत है, मेरे निर्माता एक ही (केवल एक तर्क) रहता है - कि कहीं आदि परिवर्तन की संख्या

    मुझे आशा है कि मदद मिलेगी

    +1

    यह बहुत ही बॉयलर प्लेट बनाम है। बस @Value –

    +0

    का उपयोग करके यह [टैग: जावा] है। अधिक बॉयलरप्लेट का मतलब है बेहतर कोड – Clijsters

    +0

    @ क्लाइजस्टर्स मैं ईमानदारी से यह नहीं बता सकता कि आप मुखर हैं या नहीं, मेरा मतलब है, यह बिल्कुल सही नहीं है लेकिन यह कहीं भी दूर नहीं है! –

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