Zum Hauptinhalt springen

Woche 3, Tag 3 — Auto-Konfiguration im Detail: Conditions, Back-off und Debugging

Ziel​

Heute verstehst du Spring Boot Auto-Konfiguration im Detail.

Die Kernfragen:

  1. Was ist Auto-Konfiguration?
  2. Wie entscheidet Spring Boot, was konfiguriert wird?
  3. Was sind Conditions?
  4. Was ist @ConditionalOnClass?
  5. Was ist @ConditionalOnMissingBean?
  6. Was ist @ConditionalOnProperty?
  7. Was bedeutet „Auto-Konfiguration backs off"?
  8. Wie kannst du Auto-Konfiguration überschreiben?
  9. Wie kannst du Auto-Konfiguration ausschließen?
  10. Wie kannst du Auto-Konfigurationsentscheidungen debuggen?
  11. Welche typischen Prüfungsfallen gibt es?

1. Kurz-Wiederholung aus Woche 3, Tag 2​

An Tag 2 hast du gelernt:

  • Starters sind Dependency-Bundles.
  • Starters bringen Libraries auf den Classpath.
  • Auto-Konfiguration konfiguriert Beans basierend auf diesen Libraries.
  • Spring Boot Dependency Management liefert kompatible Versionen.
  • Normalerweise gibst du für Boot-verwaltete Dependencies keine Versionen manuell an.

Merksatz:


Starters bring libraries.
Auto-configuration configures them.

Heute gehst du tiefer rein, wie Auto-Konfiguration tatsächlich entscheidet, was erzeugt wird.

2. Was ist Auto-Konfiguration?​

Auto-Konfiguration ist Spring Boots Mechanismus, Spring Beans automatisch zu konfigurieren.

Einfache Definition:

Auto-Konfiguration erzeugt und konfiguriert Beans automatisch basierend auf Classpath, Properties, vorhandenen Beans und Conditions.

Beispiel:

Wenn du hinzufügst:


implementation("org.springframework.boot:spring-boot-starter-web")

sieht Spring Boot web-bezogene Klassen und konfiguriert:


embedded Tomcat
Spring MVC
DispatcherServlet
HTTP message converters
Jackson JSON support
error handling

Du musst das nicht manuell konfigurieren.

3. Warum es Auto-Konfiguration gibt​

Ohne Auto-Konfiguration bräuchtest du viele Configuration-Klassen.

Beispiel: Für eine Web-App-Setup könntest du manuell konfigurieren müssen:


DispatcherServlet
HandlerMapping
HandlerAdapter
MessageConverters
ObjectMapper
Embedded Tomcat
Error handling
Static resources
Validation

Spring Boot sagt:

Wenn gängige Libraries vorhanden sind und keine Custom Bean sie überschreibt, kann ich sinnvolle Defaults konfigurieren.

Merksatz:

Auto-Konfiguration erspart gängiges manuelles Setup.

4. Auto-Konfiguration ist keine Magie​

Spring Boot wirkt magisch, basiert aber auf Regeln.

Es prüft:


1. Ist eine Klasse auf dem Classpath?
2. Ist eine Property aktiviert?
3. Ist das eine Web-Anwendung?
4. Existiert eine benötigte Bean schon?
5. Fehlt eine Bean?
6. Ist ein Profile aktiv?
7. Hat der User diese Auto-Konfiguration ausgeschlossen?

Dann entscheidet es, ob Beans erzeugt werden.

Merksatz:

Spring Boot Auto-Konfiguration ist bedingte Konfiguration.

5. Die Hauptidee: Conditions​

Auto-Konfiguration nutzt Conditions.

Eine Condition sagt:

Wende diese Konfiguration nur an, wenn etwas wahr ist.

Häufige Conditions:


@ConditionalOnClass
@ConditionalOnMissingBean
@ConditionalOnBean
@ConditionalOnProperty
@ConditionalOnWebApplication
@ConditionalOnNotWebApplication
@ConditionalOnResource
@ConditionalOnExpression

Du musst nicht jedes Detail auswendig kennen.

Für die Zertifizierung solltest du aber die wichtigen verstehen.

6. Beispiel einer Auto-Konfigurationsklasse​

Vereinfachtes Beispiel:


@AutoConfiguration
@ConditionalOnClass(ObjectMapper.class)
public class JacksonAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean
    public ObjectMapper objectMapper() {
        return new ObjectMapper();
    }
}

Bedeutung:


If ObjectMapper is on the classpath,
and no ObjectMapper bean already exists,
then create a default ObjectMapper bean.

Das ist die Kernidee der Auto-Konfiguration.

7. @ConditionalOnClass​

@ConditionalOnClass bedeutet:

Wende diese Konfiguration nur an, wenn eine bestimmte Klasse auf dem Classpath existiert.

Beispiel:


@ConditionalOnClass(ObjectMapper.class)

Bedeutung:


Only activate this configuration if ObjectMapper is available.

Warum nützlich?

Weil Spring Boot erkennen kann, welche Libraries du hinzugefügt hast.

Beispiel:


Jackson class present -> configure JSON support
JPA class present -> configure JPA support
Spring MVC class present -> configure web MVC
Security class present -> configure security

8. Classpath-gesteuerte Konfiguration​

Wenn du diesen Starter hinzufügst:


implementation("org.springframework.boot:spring-boot-starter-web")

bekommst du Spring-MVC-Klassen auf dem Classpath.

Dann kann Spring Boot sagen:


Spring MVC is available.
This is probably a servlet web app.
I should configure MVC infrastructure.

Wenn du den Starter entfernst, fehlen diese Klassen.

Dann passt die zugehörige Auto-Konfiguration nicht.

Merksatz:

Was auf dem Classpath liegt, beeinflusst, was Spring Boot auto-konfiguriert.

9. Praxisbeispiel: Web Starter​

Dependency:


implementation("org.springframework.boot:spring-boot-starter-web")

Klassen erscheinen auf dem Classpath:


DispatcherServlet
RequestMappingHandlerMapping
HttpMessageConverter
Tomcat classes
Jackson classes

Spring Boot auto-konfiguriert:


Spring MVC
embedded Tomcat
JSON converters
error handling
web application context

Deshalb ändert ein einziger Starter das Anwendungsverhalten.

10. @ConditionalOnMissingBean​

@ConditionalOnMissingBean bedeutet:

Erzeuge diese Bean nur, wenn der User noch keine passende Bean definiert hat.

Beispiel:


@Bean
@ConditionalOnMissingBean
public ObjectMapper objectMapper() {
    return new ObjectMapper();
}

Bedeutung:


If there is no ObjectMapper bean, create this default one.
If the user already created an ObjectMapper bean, do not create this one.

Das ist sehr wichtig.

Es erlaubt Spring Boot, Defaults zu liefern — und dir trotzdem, sie zu überschreiben.

11. Was bedeutet „Back off"?​

Wenn Auto-Konfiguration back off, bedeutet das:

Spring Boot erzeugt seine Default-Bean nicht, weil der User schon eine bereitgestellt hat.

Beispiel:

Spring Boot kann einen Default-ObjectMapper erzeugen.

Aber du definierst:


@Configuration
public class JsonConfig {

    @Bean
    public ObjectMapper objectMapper() {
        return new ObjectMapper().findAndRegisterModules();
    }
}

Dann kann Boot back off und seinen Default-ObjectMapper nicht erzeugen.

Merksatz:

Back off bedeutet: Boot tritt zurück, wenn du deine eigene Bean bereitstellst.

12. Warum Back-off nützlich ist​

Back-off liefert eine gute Balance:


Spring Boot provides defaults.
I can customize when needed.
My custom bean can replace Boot's default.

Deshalb ist Spring Boot sowohl:


opinionated

als auch:


customizable

Spring Boot liefert sinnvolle Defaults, erzwingt sie aber nicht in jedem Fall.

13. @ConditionalOnBean​

@ConditionalOnBean bedeutet:

Wende diese Konfiguration nur an, wenn eine bestimmte Bean schon existiert.

Beispiel:


@Bean
@ConditionalOnBean(DataSource.class)
public JdbcTemplate jdbcTemplate(DataSource dataSource) {
    return new JdbcTemplate(dataSource);
}

Bedeutung:


Create JdbcTemplate only if a DataSource bean exists.

Das ist nützlich, weil manche Beans nur Sinn ergeben, wenn eine andere Bean schon verfügbar ist.

14. @ConditionalOnProperty​

@ConditionalOnProperty bedeutet:

Erzeuge diese Bean nur, wenn eine Property einen bestimmten Wert hat.

Beispiel:


@Bean
@ConditionalOnProperty(
    name = "feature.audit.enabled",
    havingValue = "true"
)
public AuditService auditService() {
    return new AuditService();
}

Konfiguration:


feature:
  audit:
    enabled: true

Ergebnis:


AuditService bean is created.

Wenn die Property false ist oder fehlt, wird die Bean nicht erzeugt.

15. @ConditionalOnProperty mit matchIfMissing​

Beispiel:


@Bean
@ConditionalOnProperty(
    name = "feature.audit.enabled",
    havingValue = "true",
    matchIfMissing = true
)
public AuditService auditService() {
    return new AuditService();
}

Bedeutung:


Create the bean if feature.audit.enabled=true.
Also create it if the property is missing.

Das ist nützlich, wenn ein Feature standardmäßig aktiviert sein soll.

16. Praxisbeispiel: Feature Toggle​

YAML:


feature:
  email:
    enabled: false

Config:


@Configuration
public class EmailConfig {

    @Bean
    @ConditionalOnProperty(
        name = "feature.email.enabled",
        havingValue = "true"
    )
    public EmailSender emailSender() {
        return new SmtpEmailSender();
    }
}

Wenn feature.email.enabled=false, wird die Bean nicht erzeugt.

Wenn eine andere Bean EmailSender braucht, kann die App fehlschlagen — außer es gibt eine andere Implementierung oder die Dependency ist optional.

17. @ConditionalOnWebApplication​

@ConditionalOnWebApplication bedeutet:

Wende diese Konfiguration nur an, wenn die Anwendung eine Web-Anwendung ist.

Beispiel:


@ConditionalOnWebApplication
public class WebMvcAutoConfiguration {
}

Das macht Sinn, weil Web-MVC-Beans nur für Web-Apps erzeugt werden sollten.

Eine CLI-App oder ein Batch-Job braucht nicht:


DispatcherServlet
web error handling
web request mappings

18. @ConditionalOnNotWebApplication​

Gegenteilige Idee:


@ConditionalOnNotWebApplication

Bedeutung:


Apply this only when the application is not a web application.

Das kann für Command-Line- oder Worker-Anwendungen nützlich sein.

19. @ConditionalOnResource​

@ConditionalOnResource bedeutet:

Wende Konfiguration nur an, wenn eine Resource existiert.

Beispiel-Idee:


@ConditionalOnResource(resources = "classpath:banner.txt")

Das ist im normalen Anwendungscode seltener, taucht aber in Conditional-Configuration-Konzepten auf.

20. @ConditionalOnExpression​

@ConditionalOnExpression nutzt einen SpEL-Ausdruck.

Beispiel:


@ConditionalOnExpression("${feature.advanced:false}")

Normalerweise bevorzugst du klarere Conditions wie @ConditionalOnProperty.

Für die Prüfung:

Wisse, dass Condition-Annotationen Properties, Beans, Klassen, Web-Application-Typ oder Resources nutzen können.

21. Ablauf der Auto-Konfigurationsentscheidung​

Vereinfachter Ablauf:


1. Spring Boot finds auto-configuration classes.
2. It checks conditions.
3. If conditions match, bean definitions are registered.
4. If conditions do not match, configuration is skipped.
5. If user beans already exist, auto-configuration may back off.
6. ApplicationContext creates the final beans.

Merksatz:

Auto-Konfigurationsklassen sind Kandidaten. Conditions entscheiden, ob sie greifen.

22. Wie Auto-Konfiguration geladen wird​

Spring Boot hat Auto-Konfigurationsklassen von Boot und Libraries.

Konzeptionell:


Spring Boot reads auto-configuration metadata.
It finds candidate auto-configuration classes.
It applies conditions.
Matching configurations contribute bean definitions.

Diese Klassen importierst du normalerweise nicht manuell.

@EnableAutoConfiguration aktiviert diesen Mechanismus.

Und @SpringBootApplication enthält @EnableAutoConfiguration.

23. Wichtig: Auto-Konfiguration läuft mit User-Konfiguration​

Spring Boot kombiniert:


my @Configuration classes
my @Bean methods
my @Component classes
auto-configuration classes
external properties

Dann erzeugt es den Application Context.

Die finale Anwendung ist ein Mix aus:


my beans
Spring Framework infrastructure beans
Spring Boot auto-configured beans
third-party auto-configured beans

24. User-Beans gewinnen meist​

In vielen Fällen haben User-definierte Beans Priorität.

Beispiel:

Boot will bereitstellen:


default ObjectMapper

Aber du lieferst:


@Bean
public ObjectMapper objectMapper() {
    return new ObjectMapper();
}

Dann erzeugt Boot seinen Default möglicherweise nicht wegen:


@ConditionalOnMissingBean

Merksatz:

Spring Boot bevorzugt deine explizite Bean gegenüber seinem Default, wenn Conditions so designed sind, dass sie back off.

25. Wichtig: Nicht jede Auto-Konfiguration back off gleich​

Denk nicht, dass jede Auto-Konfiguration immer für alles back off.

Back-off hängt von der verwendeten Condition ab.

Beispiel:


@ConditionalOnMissingBean

back off, wenn eine Bean existiert.

Aber wenn die Konfiguration diese Condition nicht nutzt, kann das Verhalten anders sein.

Prüfungssichere Antwort:

Viele Auto-Konfigurationen sind bedingt und back off oft, wenn passende User-Beans existieren — häufig mit @ConditionalOnMissingBean.

26. Auto-Konfiguration mit Custom Beans überschreiben​

Beispiel: Custom Clock


@Configuration
public class TimeConfig {

    @Bean
    public Clock clock() {
        return Clock.systemUTC();
    }
}

Jeder Service kann injizieren:


public TaskService(Clock clock) {
    this.clock = clock;
}

Wenn Boot oder eine andere Library einen Default-Clock mit @ConditionalOnMissingBean hätte, würde deine Bean dazu führen, dass sie back off.

27. ObjectMapper überschreiben​

Beispiel:


@Configuration
public class JacksonConfig {

    @Bean
    public ObjectMapper objectMapper() {
        return new ObjectMapper()
                .findAndRegisterModules();
    }
}

Das kann den Default-JSON-Mapper ersetzen oder anpassen.

Aber Vorsicht.

Wenn du Boots Default-ObjectMapper komplett ersetzt, verlierst du möglicherweise einige Default-Anpassungen.

Manchmal sind Customizer besser.

28. Customizer-Pattern​

Spring Boot liefert oft Customizer-Interfaces.

Beispiel-Konzept:


@Bean
public Jackson2ObjectMapperBuilderCustomizer jsonCustomizer() {
    return builder -> builder.indentOutput(true);
}

Die Idee:


Instead of replacing the whole auto-configured bean,
customize the bean creation process.

Das ist oft sicherer als die Bean komplett zu ersetzen.

Merksatz:

Bevorzuge Customizer, wenn du nur Boot-Defaults anpassen willst.

29. Auto-Konfiguration ausschließen​

Manchmal willst du eine Auto-Konfiguration deaktivieren.

Beispiel:


@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)
public class MyApplication {
}

Das sagt Spring Boot:


Do not apply DataSourceAutoConfiguration.

Nutze das, wenn Boot etwas konfigurieren will, das du nicht willst.

30. Auto-Konfiguration in Properties ausschließen​

Alternative:


spring:
  autoconfigure:
    exclude:
      - org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

Das ist nützlich, wenn du den Ausschluss ohne Java-Code-Änderung konfigurieren willst.

31. Wann solltest du Auto-Konfiguration ausschließen?​

Schließe Ausschlüsse sorgfältig ein.

Mögliche Fälle:


Boot tries to configure a DataSource but the app has no database.
A library adds unwanted auto-configuration.
I want full manual control over a specific area.
A test wants to avoid expensive configuration.

Aber schließe nicht wahllos aus.

Verstehe zuerst, warum die Auto-Konfiguration gegriffen hat.

Nutze:


debug logs
condition report
Actuator /actuator/conditions

32. Typischer Fehler: DataSource Auto-Konfiguration​

Dependency:


implementation("org.springframework.boot:spring-boot-starter-data-jpa")

Keine DataSource-Config.

Möglicher Fehler:


Failed to configure a DataSource

Warum?

Spring Boot sieht JPA- und Datenbank-Klassen und versucht, eine DataSource zu konfigurieren.

Fix-Optionen:


configure spring.datasource.url
add database driver
add embedded database for tests
remove JPA starter if not needed
exclude DataSourceAutoConfiguration only if truly no DB is needed

33. Typischer Fehler: Security Starter ändert Verhalten​

Dependency:


implementation("org.springframework.boot:spring-boot-starter-security")

Nach dem Hinzufügen können Endpoints Authentifizierung verlangen.

Warum?

Security Auto-Konfiguration hat gegriffen, weil Spring Security auf dem Classpath ist.

Fix:


provide SecurityFilterChain bean
configure authorization rules
remove security starter if not needed

Beispiel:


@Configuration
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers("/actuator/health").permitAll()
                        .anyRequest().authenticated()
                )
                .build();
    }
}

34. Typischer Fehler: Meine Bean wird nicht genutzt​

Mögliche Gründe:


My configuration class is outside component scanning.
My bean has wrong type.
There are multiple beans and no @Primary / @Qualifier.
An auto-configured bean is still used.
My bean is behind a profile that is not active.
A condition prevents my bean from being created.
The code injects a more specific type than my bean provides.

Debuggen mit:


Actuator /actuator/beans
Actuator /actuator/conditions
startup logs

35. Wie du Auto-Konfiguration debuggst​

Gute Tools:


1. Run with --debug
2. Set debug=true
3. Use Actuator /actuator/conditions
4. Use Actuator /actuator/beans
5. Use Actuator /actuator/configprops
6. Read startup logs
7. Use dependency tree

36. --debug​

Ausführen:


java -jar app.jar --debug

oder in application.yml:


debug: true

Das druckt einen Auto-Konfigurationsreport in die Logs.

Es zeigt:


positive matches
negative matches
unconditional classes
excluded classes

Das hilft zu beantworten:


Why did this auto-configuration apply?
Why did another one not apply?

37. Actuator Conditions Endpoint​

Actuator hinzufügen:


implementation("org.springframework.boot:spring-boot-starter-actuator")

Conditions Endpoint freigeben:


management:
  endpoints:
    web:
      exposure:
        include: health,info,conditions,beans,configprops

Dann prüfen:


/actuator/conditions

Es zeigt die Condition-Evaluation.

Das ist eines der besten Debug-Tools für Auto-Konfiguration.

38. Actuator Beans Endpoint​

Endpoint:


/actuator/beans

Das hilft zu beantworten:


Which beans exist?
What is the bean name?
What is the bean type?
Which resource/configuration created it?
What dependencies does it have?

Nützlich, wenn du fragst:


Is my bean actually registered?
Did Boot create another bean?

39. Actuator Config Props Endpoint​

Endpoint:


/actuator/configprops

Das hilft, Configuration Properties zu inspizieren.

Nützlich, wenn du fragst:


Did my @ConfigurationProperties bind correctly?
What values did Boot bind?
Which configuration properties beans exist?

Vorsicht mit sensiblen Daten.

Gib in Produktion nicht zu viele Actuator-Informationen öffentlich frei.

40. Condition Report: Positive und Negative Matches​

Ein Condition Report enthält oft:


Positive matches:
- configurations that matched and applied

Negative matches:
- configurations that did not match and were skipped

Beispiel-Konzept:


WebMvcAutoConfiguration matched:
- found servlet web application
- found DispatcherServlet class

DataSourceAutoConfiguration did not match:
- no suitable DataSource property
- no embedded database found

So hörst du auf zu raten und fängst an zu debuggen.

41. Praxis-Debug-Ablauf​

Wenn Auto-Konfiguration dich überrascht, nutze diesen Ablauf:


1. Check dependencies.
2. Check active profiles.
3. Check application properties.
4. Check whether my custom bean exists.
5. Check conditions endpoint or debug report.
6. Check bean list.
7. Decide whether to customize, define a bean, change properties, or exclude auto-configuration.

Merksatz:

Debugge Auto-Konfiguration mit Classpath, Properties, Beans und Conditions.

42. Auto-Konfiguration und Properties​

Viele Auto-Konfigurationen werden über Properties gesteuert.

Beispiel:


server:
  port: 9090

Das passt den Port des embedded Servers an.

Beispiel:


spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/app
    username: postgres
    password: postgres

Das gibt der DataSource Auto-Konfiguration, was sie braucht.

Beispiel:


management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics

Das passt die Actuator Auto-Konfiguration an.

Merksatz:

Properties passen Auto-Konfiguration an.

43. Auto-Konfiguration und Profiles​

Profiles können Auto-Konfigurationsverhalten ändern, weil Profiles Properties und Beans ändern.

Beispiel:


## application-dev.yml
spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/app_dev

## application-prod.yml
spring:
  datasource:
    url: ${DB_URL}

Gleiche Auto-Konfiguration.

Andere Properties.

Anderes Ergebnis.

44. Auto-Konfiguration und vorhandene Beans​

Vorhandene Beans können Auto-Konfiguration ändern.

Beispiel:


@Bean
public DataSource dataSource() {
    return customDataSource();
}

Wenn Boot sieht, dass eine DataSource-Bean schon existiert, kann manche Auto-Konfiguration back off.

Beispiel:


User-defined DataSource exists.
Boot does not create default DataSource.

45. Auto-Konfiguration und Ordering​

Auto-Konfigurationsklassen können Ordering-Regeln haben.

Für die Prüfung musst du Ordering nicht tief auswendig kennen.

Aber verstehe die Idee:


Some auto-configurations need to run before or after others.
Spring Boot manages the order internally.

Beispiel:


DataSource should exist before JdbcTemplate can be configured.

Prüfungssicherer Satz:

Auto-Konfigurationen sind geordnet, damit abhängige Konfigurationen in sinnvoller Reihenfolge angewendet werden können.

46. Eigene bedingte Bean schreiben​

Du kannst Conditional-Annotationen auch in deiner eigenen App nutzen.

Beispiel:


@Configuration
public class AuditConfig {

    @Bean
    @ConditionalOnProperty(
        name = "app.audit.enabled",
        havingValue = "true"
    )
    public AuditService auditService() {
        return new AuditService();
    }
}

YAML:


app:
  audit:
    enabled: true

Das erzeugt AuditService.

Bei false nicht.

47. Bedingte Bean vs. Profile​

Nutze @Profile für Umgebungen:


@Profile("dev")

Nutze @ConditionalOnProperty für Feature-/Config-Schalter:


@ConditionalOnProperty(name = "feature.audit.enabled", havingValue = "true")

Merksatz:

Profiles sind für Umgebungen. Properties sind besser für Feature-Schalter.

48. Beispiel: Besser als zu viele Profiles​

Vermeide:


dev-with-audit
dev-without-audit
prod-with-audit
prod-without-audit

Besser:


profiles:
dev
prod

property:
feature.audit.enabled=true/false

Profiles beschreiben die Umgebung.

Properties beschreiben Feature-Verhalten.

49. Auto-Konfiguration in Tests​

Tests können von Auto-Konfiguration betroffen sein.

Beispiel:


@SpringBootTest

lädt einen vollen Application Context und wendet Auto-Konfiguration an.

Slice Tests laden nur einen Teil der App.

Beispiele:


@WebMvcTest
@DataJpaTest
@JsonTest

Diese Tests nutzen begrenzte Auto-Konfiguration für eine bestimmte Schicht.

Tests schauen wir später an.

Merksatz:

Verschiedene Test-Annotationen laden verschiedene Teile der Auto-Konfiguration.

50. Typische Prüfungsfallen​

Falle 1​

Auto-Konfiguration ist nicht dasselbe wie Component Scanning.


Component scanning finds my annotated classes.
Auto-configuration applies Boot configuration classes conditionally.

Falle 2​

Starters konfigurieren Beans nicht selbst.


Starters bring dependencies.
Auto-configuration configures beans.

Falle 3​

Auto-Konfiguration ist bedingt.

Sie hängt ab von:


classpath
properties
existing beans
web application type
conditions

Falle 4​

@ConditionalOnMissingBean erlaubt Boot, back off.

Falle 5​

Einen Starter hinzuzufügen kann das Verhalten ändern.

Beispiel:


Adding security starter can secure endpoints.
Adding JPA starter can trigger DataSource configuration.

Falle 6​

application-prod.yml lädt nicht, außer das prod-Profile ist aktiv.

Dieses Profile kann Auto-Konfiguration beeinflussen.

Falle 7​

Auto-Konfiguration ausschließen sollte sorgfältig erfolgen.

Normalerweise zuerst debuggen, warum sie gegriffen hat.

Falle 8​

Eine Custom Bean kann Boot-Defaults überschreiben.

Aber nicht jede Auto-Konfiguration back off auf die gleiche Weise.

Falle 9​

Actuator /actuator/conditions hilft beim Debuggen von Auto-Konfiguration.

Falle 10​

debug=true oder --debug kann die Condition-Evaluation in Logs zeigen.

51. Prüfungsfrage: Auto-Konfiguration​

Frage:

Was ist Spring Boot Auto-Konfiguration?

Antwort:

Auto-Konfiguration ist Spring Boots Mechanismus, Beans automatisch basierend auf Classpath-Dependencies, Application Properties, vorhandenen Beans, Conditions, aktiven Profiles und Application Type zu konfigurieren.

52. Prüfungsfrage: Conditions​

Frage:

Warum nutzt Spring Boot Conditions?

Antwort:

Spring Boot nutzt Conditions, damit Konfiguration nur angewendet wird, wenn es Sinn ergibt. Zum Beispiel sollte Web-MVC-Konfiguration nur greifen, wenn Web-MVC-Klassen auf dem Classpath sind und die App eine Web-Anwendung ist.

53. Prüfungsfrage: @ConditionalOnClass​

Frage:

Was macht @ConditionalOnClass?

Antwort:

Es aktiviert Konfiguration nur, wenn eine bestimmte Klasse auf dem Classpath vorhanden ist.

54. Prüfungsfrage: @ConditionalOnMissingBean​

Frage:

Was macht @ConditionalOnMissingBean?

Antwort:

Es erzeugt eine Bean nur, wenn noch keine passende Bean im Application Context existiert. Das erlaubt Auto-Konfiguration, back off, wenn der User eine Custom Bean definiert.

55. Prüfungsfrage: Back-off​

Frage:

Was bedeutet, dass Auto-Konfiguration back off?

Antwort:

Es bedeutet, Spring Boot erzeugt seine Default-Bean nicht, weil schon eine passende User-definierte Bean existiert.

56. Prüfungsfrage: @ConditionalOnProperty​

Frage:

Was macht @ConditionalOnProperty?

Antwort:

Es aktiviert Konfiguration oder erzeugt eine Bean nur, wenn eine bestimmte Property einen passenden Wert hat.

57. Prüfungsfrage: Starter vs. Auto-Konfiguration​

Frage:

Was ist der Unterschied zwischen einem Starter und Auto-Konfiguration?

Antwort:

Ein Starter bringt Dependencies auf den Classpath. Auto-Konfiguration nutzt Classpath, Properties, vorhandene Beans und Conditions, um Spring Beans zu konfigurieren.

58. Prüfungsfrage: Debugging​

Frage:

Wie kannst du Auto-Konfigurationsentscheidungen debuggen?

Antwort:

Du kannst die App mit --debug oder debug=true starten, Startup-Logs prüfen und Actuator Endpoints wie /actuator/conditions, /actuator/beans und /actuator/configprops nutzen.

59. Prüfungsfrage: Auto-Konfiguration ausschließen​

Frage:

Wie kannst du eine Auto-Konfigurationsklasse ausschließen?

Antwort:

Du kannst nutzen:


@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)

oder setzen:


spring:
  autoconfigure:
    exclude:
      - org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

60. Prüfungsfrage: Component Scan vs. Auto-Config​

Frage:

Was ist der Unterschied zwischen Component Scanning und Auto-Konfiguration?

Antwort:

Component Scanning findet deine Anwendungsklassen mit Stereotypes wie @Service, @Repository und @Controller. Auto-Konfiguration wendet Spring Boot Configuration-Klassen bedingt basierend auf Classpath, Properties und vorhandenen Beans an.

61. Interview-Antwort​

Frage:

Explain Spring Boot auto-configuration.

Gute Antwort:

Spring Boot Auto-Konfiguration konfiguriert Spring Beans automatisch basierend auf dem, was es in der Anwendung findet. Es prüft Classpath-Dependencies, Application Properties, vorhandene Beans, aktive Profiles, Application Type und Conditions. Wenn Spring MVC und Tomcat auf dem Classpath sind, kann Boot zum Beispiel eine Servlet-Web-Anwendung konfigurieren. Auto-Konfiguration ist bedingt und back off oft, wenn du deine eigene Bean bereitstellst.

62. Interview-Antwort​

Frage:

What does it mean that auto-configuration is conditional?

Gute Antwort:

Es bedeutet, Spring Boot konfiguriert nicht blind alles. Auto-Konfigurationsklassen und Bean-Methoden haben Conditions wie @ConditionalOnClass, @ConditionalOnMissingBean, @ConditionalOnProperty und @ConditionalOnWebApplication. Diese Conditions entscheiden, ob eine Konfiguration greifen soll. So kann Spring Boot sich an Dependencies und Einstellungen der Anwendung anpassen.

63. Interview-Antwort​

Frage:

What does auto-configuration back-off mean?

Gute Antwort:

Back-off bedeutet, Spring Boot entscheidet sich, keine Default-Bean zu erzeugen, weil der User schon eine passende Bean definiert hat. Das wird häufig mit @ConditionalOnMissingBean umgesetzt. So kann Boot nützliche Defaults liefern — und Entwickler können die Anwendung trotzdem anpassen, indem sie eigene Beans definieren.

64. Interview-Antwort​

Frage:

How do you override Spring Boot auto-configuration?

Gute Antwort:

Du kannst Auto-Konfiguration überschreiben, indem du deine eigene Bean vom benötigten Typ definierst, Configuration Properties änderst, Customizer-Beans nutzt oder bei Bedarf eine bestimmte Auto-Konfigurationsklasse ausschließt. Normalerweise versuchst du zuerst, mit Properties oder Customizern anzupassen. Wenn du volle Kontrolle brauchst, definierst du deine eigene Bean. Auto-Konfiguration ausschließen solltest du sorgfältig tun, nachdem du verstanden hast, warum sie gegriffen hat.

65. Interview-Antwort​

Frage:

How do you debug auto-configuration problems?

Gute Antwort:

Ich prüfe zuerst Dependencies, aktive Profiles und Application Properties. Dann nutze ich --debug oder debug=true, um den Condition-Evaluation-Report zu sehen. Wenn Actuator aktiviert ist, schaue ich /actuator/conditions, um zu sehen, welche Auto-Konfigurationen gegriffen haben oder nicht, /actuator/beans, um zu sehen, welche Beans existieren, und /actuator/configprops, um Configuration Properties zu inspizieren.

66. Kleine Code-Übung​

Erzeuge eine bedingte Bean:


@Configuration
public class AuditConfig {

    @Bean
    @ConditionalOnProperty(
        name = "app.audit.enabled",
        havingValue = "true"
    )
    public AuditService auditService() {
        return new AuditService();
    }
}

Config:


app:
  audit:
    enabled: true

Fragen:

  1. Wird AuditService erzeugt?
  2. Was passiert bei app.audit.enabled=false?
  3. Ist das besser als Profile oder Property?

Antworten:

  1. Ja.
  2. Nein, die Bean wird nicht erzeugt.
  3. Besser als Property, weil das ein Feature-Schalter ist — keine Umgebung.

67. Kleines Bug-Übungsbeispiel 1 — DataSource​

Problem:


implementation("org.springframework.boot:spring-boot-starter-data-jpa")

Fehler:


Failed to configure a DataSource

Frage:

Warum ist das passiert?

Antwort:

Der JPA Starter bringt JPA- und datenbankbezogene Klassen auf den Classpath. Spring Boots DataSource Auto-Konfiguration greift und versucht, eine DataSource zu erzeugen. Wenn keine Datenbank-URL, kein Driver und keine embedded Database verfügbar ist, schlägt die App fehl.

Fix-Optionen:


configure datasource
add database driver
use embedded database for tests
remove JPA starter if not needed
exclude DataSourceAutoConfiguration only if truly no database is needed

68. Kleines Bug-Übungsbeispiel 2 — Security​

Problem:

Du fügst hinzu:


implementation("org.springframework.boot:spring-boot-starter-security")

Plötzlich verlangen alle Endpoints Login.

Frage:

Warum?

Antwort:

Spring Security ist jetzt auf dem Classpath. Security Auto-Konfiguration greift und wendet Default-Security-Verhalten an. Um es anzupassen, definiere eine SecurityFilterChain-Bean oder konfiguriere Security Properties.

69. Kleines Bug-Übungsbeispiel 3 — Custom Bean wird nicht genutzt​

Problem:

Du erzeugst:


@Configuration
public class MyJsonConfig {

    @Bean
    public ObjectMapper objectMapper() {
        return new ObjectMapper();
    }
}

Aber es scheint das JSON-Verhalten nicht zu beeinflussen.

Mögliche Gründe:


configuration class is outside component scan
another ObjectMapper is used
multiple ObjectMapper-like beans exist
custom bean has wrong type
test slice does not load this configuration
profile or condition prevents config from loading

Debuggen mit:


/actuator/beans
/actuator/conditions
debug logs

Übungsfragen​

Frage 1​

Was ist Auto-Konfiguration?

Antwort:

Auto-Konfiguration ist Spring Boots Mechanismus, Beans automatisch basierend auf Classpath-Dependencies, Properties, vorhandenen Beans, Conditions, aktiven Profiles und Application Type zu konfigurieren.

Frage 2​

Warum nutzt Spring Boot Auto-Konfiguration?

Antwort:

Spring Boot nutzt Auto-Konfiguration, um manuelles Setup zu reduzieren und sinnvolle Defaults für gängige Anwendungsfeatures wie Web, JPA, Security, JSON und Actuator zu liefern.

Frage 3​

Warum ist Auto-Konfiguration keine Magie?

Antwort:

Auto-Konfiguration ist keine Magie, weil sie auf klaren Mechanismen basiert: Classpath-Erkennung, Conditional-Annotationen, externe Properties, vorhandene Beans und dem Spring IoC Container.

Frage 4​

Was sind Conditions?

Antwort:

Conditions sind Regeln, die entscheiden, ob eine Configuration-Klasse oder Bean angewendet werden soll.

Frage 5​

Was macht @ConditionalOnClass?

Antwort:

@ConditionalOnClass wendet Konfiguration nur an, wenn eine bestimmte Klasse auf dem Classpath vorhanden ist.

Frage 6​

Was macht @ConditionalOnMissingBean?

Antwort:

@ConditionalOnMissingBean erzeugt eine Bean nur, wenn noch keine passende Bean existiert.

Frage 7​

Was bedeutet Auto-Konfiguration back off?

Antwort:

Back off bedeutet, Spring Boot erzeugt seine Default-Bean nicht, weil der User schon eine passende Bean bereitgestellt hat.

Frage 8​

Was macht @ConditionalOnBean?

Antwort:

@ConditionalOnBean wendet Konfiguration nur an, wenn eine bestimmte Bean schon existiert.

Frage 9​

Was macht @ConditionalOnProperty?

Antwort:

@ConditionalOnProperty wendet Konfiguration nur an, wenn eine bestimmte Property einen passenden Wert hat.

Frage 10​

Was macht @ConditionalOnWebApplication?

Antwort:

@ConditionalOnWebApplication wendet Konfiguration nur an, wenn die Anwendung eine Web-Anwendung ist.

Frage 11​

Was ist der Unterschied zwischen Component Scanning und Auto-Konfiguration?

Antwort:

Component Scanning findet deine Anwendungsklassen mit Stereotypes wie @Service, @Repository und @Controller. Auto-Konfiguration wendet Spring Boot Configuration-Klassen bedingt basierend auf Classpath, Properties, vorhandenen Beans und Application Type an.

Frage 12​

Was ist der Unterschied zwischen einem Starter und Auto-Konfiguration?

Antwort:

Ein Starter bringt Dependencies auf den Classpath. Auto-Konfiguration konfiguriert Beans basierend auf diesen Dependencies und anderen Conditions.

Frage 13​

Wie kannst du eine Boot-Default-Bean überschreiben?

Antwort:

Du kannst eine Boot-Default-Bean überschreiben, indem du deine eigene Bean vom erwarteten Typ definierst, Configuration Properties änderst, einen Customizer nutzt oder bei Bedarf die Auto-Konfiguration ausschließt.

Frage 14​

Warum kann ein Customizer besser sein als eine ganze Bean zu ersetzen?

Antwort:

Ein Customizer ist oft besser, weil er Boots Default-Konfiguration anpasst, ohne die ganze Bean zu ersetzen und andere von Boot gelieferte Anpassungen zu verlieren.

Frage 15​

Wie kannst du eine Auto-Konfigurationsklasse ausschließen?

Antwort:

Du kannst eine Auto-Konfigurationsklasse ausschließen mit:


@SpringBootApplication(exclude = SomeAutoConfiguration.class)

oder mit:


spring:
  autoconfigure:
    exclude:
      - fully.qualified.AutoConfigurationClassName

Frage 16​

Wann solltest du Auto-Konfiguration ausschließen?

Antwort:

Schließe Auto-Konfiguration nur aus, wenn du verstehst, warum sie gegriffen hat, und du sie wirklich nicht willst. Normalerweise solltest du zuerst Properties, Custom Beans oder Customizer versuchen.

Frage 17​

Wie kannst du Auto-Konfiguration debuggen?

Antwort:

Du kannst Auto-Konfiguration debuggen mit --debug, debug=true, Startup-Logs, Actuator /actuator/conditions, /actuator/beans, /actuator/configprops und Dependency-Tree-Tools.

Frage 18​

Was zeigt /actuator/conditions?

Antwort:

/actuator/conditions zeigt, welche Auto-Konfigurations-Conditions gegriffen haben oder nicht — und warum.

Frage 19​

Was zeigt /actuator/beans?

Antwort:

/actuator/beans zeigt, welche Beans im Application Context existieren — inklusive Bean-Namen, Typen, Dependencies und Quellen.

Frage 20​

Warum kann das Hinzufügen eines Starters das Anwendungsverhalten ändern?

Antwort:

Ein Starter bringt neue Klassen auf den Classpath. Auto-Konfiguration kann diese Klassen erkennen und neue Beans erzeugen oder Default-Verhalten ändern — zum Beispiel Security aktivieren oder eine DataSource konfigurieren.

Merksätze zum Mitnehmen​

  • Auto-Konfiguration ist bedingte Bean-Konfiguration.
  • Spring Boot prüft Classpath, Properties, vorhandene Beans, Profiles und Application Type.
  • @ConditionalOnClass prüft, ob eine Klasse existiert.
  • @ConditionalOnMissingBean erzeugt eine Bean nur, wenn noch keine passende Bean existiert.
  • Back off bedeutet: Boot erzeugt seinen Default nicht, weil du deine eigene Bean bereitgestellt hast.
  • @ConditionalOnBean erfordert eine vorhandene Bean.
  • @ConditionalOnProperty hängt von Property-Werten ab.
  • @ConditionalOnWebApplication hängt vom Web-Application-Typ ab.
  • Starters bringen Dependencies; Auto-Konfiguration konfiguriert sie.
  • Component Scanning findet deine Klassen; Auto-Konfiguration wendet Boot-Konfiguration an.
  • Properties passen Auto-Konfiguration an.
  • Custom Beans können Boot-Defaults überschreiben.
  • Customizer können Boot-Defaults sicher anpassen.
  • Auto-Konfiguration kann ausgeschlossen werden — aber sorgfältig.
  • Nutze --debug oder debug=true, um Auto-Konfigurationsentscheidungen zu inspizieren.
  • Nutze Actuator /actuator/conditions, um passende Conditions zu debuggen.
  • Nutze Actuator /actuator/beans, um registrierte Beans zu sehen.