Spring Boot configuration को externalize करता है ताकि वही jar हर environment में चले। आप settings को application.yml (या .properties) में रखते हैं, उन्हें अपने code में पढ़ते हैं, और profiles के साथ प्रति-environment behavior बदलते हैं।
@Component
public class SearchService {
// Inject a single property; :20 is the fallback if it is missing.
@Value("${app.page-size:20}")
private int pageSize;
}
एक-दो values से आगे किसी भी चीज़ के लिए, @Value को बिखेरने के बजाय एक typed object bind करें:
@Component
@ConfigurationProperties(prefix = "app") // binds app.* into these fields
public class AppProps {
private int pageSize;
private Map<String, Boolean> featureFlags;
// getters/setters — Boot relaxed-binds page-size -> pageSize
}
यह आपको type safety, IDE auto-complete, और validation (@Validated + constraints जोड़ें) देता है।
spring:
config:
activate:
on-profile: prod # only when 'prod' is active
server:
port: 80
application-dev.yml और application-prod.yml जैसी files base के ऊपर layer हो जाती हैं। किसी एक को --spring.profiles.active=prod या SPRING_PROFILES_ACTIVE env var से सक्रिय करें। प्राथमिकता का क्रम मायने रखता है: command-line args और environment variables files को override करते हैं, इसलिए secrets jar से बाहर रहते हैं।
Interviewer यह जाँच रहे हैं कि आप एक ही artifact को dev/staging/prod में बिना rebuild किए ship कर सकते हैं। बिखरे हुए @Value के बजाय @ConfigurationProperties का, और secrets के लिए files को override करते env-vars का उल्लेख करना दिखाता है कि आपने Boot apps को केवल locally नहीं, बल्कि production में चलाया है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें