Spring Boot & Auto-configuration interview questions & answers

Spring Boot koi naya framework nahi hai. Wo Spring hi hai, saath me kuch defaults jo aapko wahi configuration likhne se bacha lete hain jo aap waise bhi usi tarah likhte.

Ye baat marketing lagti hai, jab tak aap is lesson ka program chala kar na dekh lein. Output ki pehli line dekhiye: context class hai AnnotationConfigApplicationContext. Yahi wo class hai jo pichhle chapter (Spring Core) me padhi thi. Boot ne container ko, beans ko, dependency injection ko - kisi ko bhi replace nahi kiya. Usne wahi container aapke liye start kar diya.

Boot asal me kya jodta hai

Chaar cheezein, aur inhe interview me ginwa pana zaroori hai:

1. Auto-configuration. Boot dekhta hai ki aapke classpath par kya pada hai, aur us combination ko jo beans aam taur par chahiye wo register kar deta hai. Classpath par Tomcat hai to web server configure ho jaata hai; Jackson hai to JSON conversion.
2. Starters. Ek dependency line jo poora ek set le aati hai, un versions par jo aapas me chalna jaante hain - aapko haath se version chunne nahi padte.
3. Ek embedded server. Aapki application apna Tomcat khud JVM ke andar start karti hai. Na WAR banana, na alag se server install karna.
4. Production ke liye taiyaar features. Health check, metrics waghairah Actuator ke through.

Wo naap jo baat ko theek se pakka karta hai

Is lesson ka program apni ek bhi bean define nahi karta. Ek annotation hai aur ek main method. Chalaiye, aur container batata hai 175 bean definitions.

Ye saari beans auto-configuration ne classpath padh kar banayi. Aur asli baat ye hai: ye number yaad karne wala constant nahi hai - ye poori tarah is par depend karta hai ki kaunsi jars maujood hain. Ek library jodiye, number badh jaata hai, aur uske saath behaviour bhi badal jaata hai - bina aapke ek line code badle. Poore chapter ka mechanism yahi hai, ek integer me dikhta hua.

Wo teen jawab jo kabhi Spring ke the hi nahi

Spring Core chapter me aapne dekha tha ki @Value("${some.key}") tabhi resolve hota hai jab PropertySourcesPlaceholderConfigurer register ho, @Repository tabhi vendor exception translate karta hai jab uska post-processor register ho, aur AOP annotations tabhi asar dikhati hain jab proxying on ho. Plain container par teenon me se kuch bhi apne aap nahi hota.

Output ki teesri line faisla kar deti hai: placeholder bean : 1. Wo post-processor Boot ne register kiya. To jab koi kehta hai "Spring ${...} khud resolve kar deta hai", to sach ye hai ki wo Spring Boot karta hai. Zyadatar developers ko ye farq pata hi nahi chalta, kyunki unhone kabhi plain container chalaya hi nahi.

Kab use karein: kisi bhi nayi Spring application ke liye - REST API, scheduled job, message consumer, command-line tool. Convention over configuration yahan naara nahi hai; iska matlab hai ki defaults wahi chunav hain jo ek tajurbekaar team karti, isliye aapko configuration sirf wahan likhni padti hai jahan aapki zaroorat aam case se sach me alag ho.

Kab NAHI use karein: Boot wahan theek nahi baithta jahan aapko aise deployment me fit hona hai jiska server kisi aur ke haath me hai - jaise koi organisation jo WAR file bana kar managed application server par deploy karti hai. Aur jab aapko application nahi, ek chhoti library banani ho tab bhi ye galat auzaar hai, kyunki Boot ki keemat application ko jodne me hai. Ek asli keemat tab bhi hai jab wo theek baithta hai: Boot application bahut kuch aisa karti hai jo aapne likha hi nahi, to jab kuch anokha bartaav kare to aapko padhna aana chahiye ki auto-configuration ne kya faisla liya. Wahi hunar is poore chapter ka baaki hissa hai.

Mechanism seekhne ki wajah - us boilerplate ki jagah jo wo hatata hai - saaf hai: interview me aapse Boot ki taareef karne ko shayad hi kaha jaye. Poochha ye jaata hai ki bean kyun nahi bani, property kyun nahi padhi ja rahi, ya application colleague ki machine par alag kyun start hoti hai. In teenon sawaalon ki jad auto-configuration hai.

package demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.context.support.PropertySourcesPlaceholderConfigurer;

@SpringBootApplication
public class WhyBoot {
  public static void main(String[] args) {
    System.setProperty("spring.main.web-application-type", "none");
    try (ConfigurableApplicationContext ctx = SpringApplication.run(WhyBoot.class, args)) {
      System.out.println("context class    : " + ctx.getClass().getSimpleName());
      System.out.println("beans registered : " + ctx.getBeanDefinitionCount());

      String[] placeholder = ctx.getBeanNamesForType(PropertySourcesPlaceholderConfigurer.class);
      System.out.println("placeholder bean : " + placeholder.length
          + (placeholder.length > 0 ? " (" + placeholder[0] + ")" : ""));
    }
  }
}

Auto-configuration wahi ek idea hai jis par ye poora chapter khada hai. Spring Boot ke lagbhag saare interview sawaal jo dekhne me kuch aur lagte hain - "ye bean kyun nahi bani", "library jodne se behaviour kyun badal gaya", "meri machine par kyun chalta hai" - asal me isi ke baare me hote hain.

Mechanism ke teen step hain, aur inme se koi bhi jaadu nahi hai.

Step 1: candidates ki ek list

Jo bhi jar auto-configuration dena chahti hai, wo ek saada text file rakhti hai - META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. Har line par ek poora class naam.

Neeche wala program us file ko kisi ke bataye bharose par nahi, apne hi classpath se padh kar dikhata hai. Is classpath par aisi 2 files hain - ek spring-boot-autoconfigure se, ek spring-boot-actuator-autoconfigure se - aur dono milakar 279 candidate classes ginwati hain.

Is file ka naam yaad rakhne layak hai. Purane tutorials batayenge ki ye list spring.factories me hoti hai. Wo Boot 2.7 tak sach tha; Boot 3 se mechanism AutoConfiguration.imports hai, aur interview me purana naam lena aapko turant purana sabit kar deta hai.

Step 2: conditions tay karti hain kaun bachega

279 candidates par vichaar hota hai. 279 ke aaspaas bhi apply nahi hote. Har candidate par conditions lagi hoti hain - ye class classpath par hai kya, user ne ye bean pehle se bana to nahi di, ye property set hai kya - aur jiski condition fail ho jaye wo kuch bhi nahi jodta. Conditions ka apna alag topic hai; yahan samajhne wali baat itni hai ki ye list candidates ki hai, faislon ki nahi.

Step 3: jo bache, unka aapas me order

Kuch auto-configurations tabhi maayne rakhti hain jab kuch doosri pehle chal chuki hon. Output me WebMvcAutoConfiguration khud bata rahi hai ki wo DispatcherServletAutoConfiguration, TaskExecutionAutoConfiguration aur ValidationAutoConfiguration ke baad chalti hai.

Dhyan dijiye ye naapa kaise gaya. Us class par @AutoConfigureAfter annotation hai hi nahi - program isi check par false chhapta hai. Boot 3 me order @AutoConfiguration annotation ke apne after aur afterName attributes se declare hota hai. @AutoConfigureAfter abhi bhi maujood hai aur chalta bhi hai, par framework ki apni classes aage badh chuki hain - to sirf usi ke around bana hua jawab ek purane Boot ka varnan karta hai, us Boot ka nahi jis par aapko kaam milega.

Iski asli keemat kitni hai

Output ki pehli do lines is feature ka imaandaar paimana hain. Ek plain @Configuration khaali Spring container me 6 bean definitions banata hai - sirf Spring ka apna infrastructure. Sirf annotation badliye, aur @SpringBootApplication 176 bana deta hai.

176 ko yaad mat kijiye. Isi chapter ke pichhle lesson me isi machine par 156, 175 aur 177 naape gaye the, kyunki har baar classpath aur scan hone wala package alag tha. Jo bean count jar jodne par hil jaye, wo demo ki kharabi nahi hai - wahi feature hai, numbers me likha hua.

Kab use karein: application ke aam hisson ke liye auto-configuration par bharosa kijiye - web server, JSON conversion, properties se datasource. Ye wahan sabse achha hai jahan aapki zaroorat wahi hai jo zyadatar applications ki hoti hai, aur wo zyadatar waqt hoti hai.

Trade-off kya hai: aapko chalti hui application milti hai, badle me ek aisa system jo wo faisle le chuka hai jo aapne dekhe hi nahi. Jab behaviour chaunkaye, tab ye keemat chukani padti hai, aur chukane ka ek hi tareeka hai - andaza lagane ki jagah padhna ki auto-configuration ne asal me kya tay kiya. Wo report is chapter me aage aati hai. Abhi jo aadat banani hai wo yahi lesson dikha raha hai: jab jaanna ho ki Boot ne kya kiya, to chalti hui application se poochhiye - count chhapiye, imports file padhiye, annotation par reflection kijiye - kisi blog post par bharosa mat kijiye.

@EnableAutoConfiguration wahi switch hai jo ye sab shuru karta hai. @SpringBootApplication usi ko apne andar rakhta hai, isliye aapko wo alag se likhna shayad hi padta hai.

package auto2;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.AutoConfiguration;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Configuration;

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.URL;
import java.util.Enumeration;

public class HowAuto {

  @Configuration
  static class PlainConfig { }

  @SpringBootApplication
  static class BootApp { }

  static final String IMPORTS =
      "META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports";

  public static void main(String[] args) throws Exception {
    try (var plain = new AnnotationConfigApplicationContext(PlainConfig.class)) {
      System.out.println("plain @Configuration beans   : " + plain.getBeanDefinitionCount());
    }

    System.setProperty("spring.main.web-application-type", "none");
    try (ConfigurableApplicationContext boot = SpringApplication.run(BootApp.class, args)) {
      System.out.println("@SpringBootApplication beans : " + boot.getBeanDefinitionCount());
    }

    int files = 0, candidates = 0;
    Enumeration<URL> urls = HowAuto.class.getClassLoader().getResources(IMPORTS);
    while (urls.hasMoreElements()) {
      files++;
      try (BufferedReader r = new BufferedReader(
          new InputStreamReader(urls.nextElement().openStream()))) {
        String line;
        while ((line = r.readLine()) != null) {
          line = line.trim();
          if (!line.isEmpty() && !line.startsWith("#")) candidates++;
        }
      }
    }
    System.out.println("imports files on classpath   : " + files);
    System.out.println("candidates listed in them    : " + candidates);

    Class<?> webmvc = Class.forName(
        "org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration");
    System.out.println("@AutoConfigureAfter present  : "
        + (webmvc.getAnnotation(org.springframework.boot.autoconfigure.AutoConfigureAfter.class) != null));
    AutoConfiguration meta = webmvc.getAnnotation(AutoConfiguration.class);
    System.out.print("WebMvc runs after            :");
    for (String n : meta.afterName()) System.out.print(" " + n.substring(n.lastIndexOf('.') + 1));
    for (Class<?> c : meta.after()) System.out.print(" " + c.getSimpleName());
    System.out.println();
  }
}

Ye chapter ka entry project hai. Ye jaan-boojh kar chhota hai - ek file, koi database nahi - kyunki asli baat URL shortener nahi hai. Asli baat ye hai ki ab tak seekhi hui har Boot ki cheez itni si service me dikh jaati hai, aur interviewer isi ek screen ke code se kisi bhi cheez par sawaal poochh sakta hai.

Ye karta kya hai

POST /links ek target URL leta hai aur ek chhota code lautata hai. GET /{code} original par redirect kar deta hai. Anjaan code par theek error banta hai, aur galat request body aapke code ke chalne se pehle hi reject ho jaati hai.

Isme kya-kya lagta hai, aur har tukda aaya kahan se

Typed configuration. shortener.base-url aur shortener.code-length ek @ConfigurationProperties class par bind hote hain jis par @Validated laga hai. Runtime par kisi string key se kuch nahi padha jaata. Agar koi khaali base URL ke saath deploy kare to application start hone se mana kar deti hai, bajaye iske ki toote hue short links serve karti rahe.

Constructor injection. Links Props leta hai, aur Api Links - wahi dependency injection jo Spring Core chapter me thi, bilkul waise ki waise. Boot ne use replace nahi kiya; usne bas container aapke liye bana diya.

Layer wala shape. Controller HTTP dekhta hai, @Service logic rakhta hai, properties class configuration. Yahi alagav service ko testable banata hai, aur jab interviewer kehta hai "ek endpoint design kijiye" tab wo yahi dhoondh raha hota hai.

Sahi HTTP. POST /links 201 aur ek Location header lautata hai, sirf body wala 200 nahi. GET /{code} 302 lautata hai jisme target Location me hota hai - protocol ke star par redirect asal me yahi hai. Ye wahi status codes hain jinhe chunne ke liye ResponseEntity hai.

Asli error handling. Anjaan code ek domain exception phenkta hai, aur ek @RestControllerAdvice use ProblemDetail bana deta hai:

404 {"type":"about:blank","title":"Unknown short code",
     "status":404,"detail":"code not found: zzzzzz","instance":"/zzzzzz"}

Gaur kijiye ki yahan type about:blank hai - handler ne title aur detail to diye par koi type URI nahi, aur RFC 7807 ka default yahi hai. Ek asli type URI set karna production service me ek line ka sudhaar hai jo karna chahiye.

Kinare par validation. @Valid @RequestBody aur @NotBlank khaali URL ko 400 se rok dete hain, business logic ki ek line chalne se pehle.

Ye kar ke dekhiye

1. Error response behtar kijiye: ProblemDetail ko asli type URI dijiye, aur MethodArgumentNotValidException ke liye handler jodiye taaki 400 ye bhi bataye ki kaunsa field fail hua, sirf "Bad Request" nahi.
2. Hash wale code ki jagah random code laiye, aur us collision ko sambhaaliye jo tab mumkin ho jaata hai - ye asli design ka sawaal hai, koi rasm nahi.
3. @ConditionalOnProperty jodiye taaki shortener.stats.enabled flag se ek optional hit-counter endpoint on/off ho, aur condition report se confirm kijiye ki flag band hone par wo sach me gayab hai.
4. Actuator me sirf health aur metrics expose kijiye, phir jaanchiye ki /actuator/env abhi bhi 404 hai.

Imaandaar chetavni: store ek ConcurrentHashMap hai, isliye restart par sab kuch gayab ho jaata hai aur instances ke beech kuch saanjha nahi hota. Ye jaan-boojh kar hai - persistence agle chapter ka vishay hai, aur use yahan jodne se Boot ke concepts JPA ke setup ke neeche dab jaate.

package shortener;

@SpringBootApplication
@EnableConfigurationProperties(Shortener.Props.class)
public class Shortener {

  @Validated
  @ConfigurationProperties(prefix = "shortener")
  public static class Props {
    @NotBlank private String baseUrl;
    private int codeLength = 6;
    public void setBaseUrl(String v){ this.baseUrl=v; } public String getBaseUrl(){ return baseUrl; }
    public void setCodeLength(int v){ this.codeLength=v; } public int getCodeLength(){ return codeLength; }
  }

  record CreateRequest(@NotBlank String url) { }
  record CreateResponse(String code, String shortUrl, String target) { }
  static class UnknownCode extends RuntimeException { UnknownCode(String c){ super("code not found: " + c); } }

  @Service
  static class Links {
    private final Map<String, String> store = new ConcurrentHashMap<>();
    private final Props props;
    Links(Props props) { this.props = props; }          // constructor injection

    CreateResponse create(String target, int port) {
      String code = Integer.toHexString(target.hashCode()).replace("-", "");
      code = (code + "000000").substring(0, props.getCodeLength());
      store.put(code, target);
      return new CreateResponse(code, props.getBaseUrl() + ":" + port + "/" + code, target);
    }
    String resolve(String code) {
      String t = store.get(code);
      if (t == null) throw new UnknownCode(code);
      return t;
    }
  }

  @RestController
  static class Api {
    private final Links links;
    private final Environment env;
    Api(Links links, Environment env) { this.links = links; this.env = env; }

    @PostMapping("/links")
    ResponseEntity<CreateResponse> create(@Valid @RequestBody CreateRequest req) {
      int port = Integer.parseInt(env.getProperty("local.server.port", "0"));
      CreateResponse r = links.create(req.url(), port);
      return ResponseEntity.created(URI.create(r.shortUrl())).body(r);
    }

    @GetMapping("/{code}")
    ResponseEntity<Void> follow(@PathVariable("code") String code) {
      return ResponseEntity.status(HttpStatus.FOUND).location(URI.create(links.resolve(code))).build();
    }
  }

  @RestControllerAdvice
  static class Errors {
    @ExceptionHandler(UnknownCode.class)
    ProblemDetail unknown(UnknownCode e) {
      ProblemDetail pd = ProblemDetail.forStatusAndDetail(HttpStatus.NOT_FOUND, e.getMessage());
      pd.setTitle("Unknown short code");
      return pd;
    }
  }
}

# application.properties
#   shortener.base-url=http://localhost
#   shortener.code-length=6