Woche 3 — Review: Spring Boot Auto-Konfiguration, Actuator und Startup

Ziel

Dieses Review prüft, ob du Woche 3 wirklich verstanden hast.

Themen aus Woche 3:

Spring Boot Mental Model
@SpringBootApplication
@Configuration
@EnableAutoConfiguration
@ComponentScan
Spring Boot starters
Dependency management
Auto-Konfiguration
Conditions
Back-off
Actuator
Health endpoint
Metrics endpoint
Beans endpoint
Conditions endpoint
Application startup
SpringApplication.run
CommandLineRunner
ApplicationRunner
Application events
Lazy initialization
Startup debugging

1. Das große Bild aus Woche 3

Woche 1 hat beantwortet:


Wie erzeugt Spring Objekte und verbindet sie?

Woche 2 hat beantwortet:

Wie konfiguriert, aktiviert, scoped, initialisiert und zerstört Spring diese Beans?

Woche 3 beantwortet:

Wie macht Spring Boot Spring-Anwendungen einfacher zu konfigurieren, zu starten, zu überwachen und zu debuggen?

Spring Boot ergänzt:

starter dependencies
auto-configuration
embedded server
external configuration conventions
Actuator
startup runners
application events
production-ready monitoring
debugging tools

Merksatz:

Spring Framework ist das Fundament.
Spring Boot macht Spring einfacher zu konfigurieren, zu starten, zu überwachen und zu deployen.

2. Zentrale Merksätze

Auswendig lernen:

Spring Boot baut auf dem Spring Framework auf.

Spring Framework liefert IoC, DI, AOP, MVC, Transactions und Bean Lifecycle.

Spring Boot ergänzt starters, auto-configuration, embedded server support, external configuration conventions und Actuator.

@SpringBootApplication enthält @Configuration, @EnableAutoConfiguration und @ComponentScan.

@Configuration erlaubt Bean-Definitionen.

@ComponentScan findet deine Application Components.

@EnableAutoConfiguration aktiviert Spring Boot auto-configuration.

Starters bringen Dependencies.

Auto-configuration konfiguriert Beans basierend auf Dependencies und Conditions.

Starter legt Libraries auf den Classpath.

Auto-configuration sieht diese Libraries und konfiguriert sie.

Spring Boot dependency management liefert kompatible Dependency-Versionen.

Normalerweise gibst du für Boot-verwaltete Dependencies keine Versionen manuell an.

Auto-configuration ist conditional.

@ConditionalOnClass prüft, ob eine Klasse auf dem Classpath existiert.

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

Back-off heißt: Boot erzeugt seinen Default nicht, weil du deine eigene Bean bereitgestellt hast.

@ConditionalOnProperty erzeugt Konfiguration basierend auf Property-Werten.

Component scanning findet deine Klassen.

Auto-configuration wendet Boot-Konfigurationsklassen an.

Actuator liefert production-ready Monitoring- und Management-Endpoints.

Der Standard-Actuator-Basispfad ist /actuator.

Standardmäßig sind nur wenige Endpoints über HTTP exposed.

Exponiere sensible Actuator-Endpoints nicht öffentlich.

Health zeigt App-Health.

Metrics zeigt Runtime-Messwerte.

Beans zeigt registrierte Spring Beans.

Conditions zeigt Auto-Konfigurationsentscheidungen.

Configprops zeigt configuration properties.

SpringApplication.run startet die Spring Boot-Anwendung.

CommandLineRunner bekommt rohe String-Args.

ApplicationRunner bekommt geparste ApplicationArguments.

Runners laufen nach dem Start des Application Context.

ApplicationReadyEvent kommt nach den Runners.

Lazy initialization erzeugt Beans erst, wenn sie zum ersten Mal gebraucht werden.

Lazy initialization kann den Startup verbessern, aber Fehler verzögern.

3. Concept Map

Spring Boot
│
├── Main Application
│   ├── @SpringBootApplication
│   ├── @Configuration
│   ├── @EnableAutoConfiguration
│   └── @ComponentScan
│
├── Starters
│   ├── spring-boot-starter-web
│   ├── spring-boot-starter-data-jpa
│   ├── spring-boot-starter-security
│   ├── spring-boot-starter-validation
│   ├── spring-boot-starter-actuator
│   └── spring-boot-starter-test
│
├── Dependency Management
│   ├── parent POM
│   ├── BOM
│   ├── managed versions
│   └── transitive dependencies
│
├── Auto-Configuration
│   ├── @ConditionalOnClass
│   ├── @ConditionalOnMissingBean
│   ├── @ConditionalOnBean
│   ├── @ConditionalOnProperty
│   ├── @ConditionalOnWebApplication
│   └── back-off
│
├── Actuator
│   ├── health
│   ├── info
│   ├── metrics
│   ├── beans
│   ├── conditions
│   ├── configprops
│   ├── env
│   └── loggers
│
└── Startup
    ├── SpringApplication.run
    ├── ApplicationContext refresh
    ├── CommandLineRunner
    ├── ApplicationRunner
    ├── ApplicationReadyEvent
    ├── ApplicationFailedEvent
    └── lazy initialization

4. Wichtigste Prüfungsfallen

Falle 1 — Spring vs. Spring Boot

Falsch:


Spring Boot ersetzt Spring Framework.

Richtig:


Spring Boot nutzt Spring Framework und ergänzt Convenience-Features.

Falle 2 — `@SpringBootApplication`

Falsch:

@SpringBootApplication ist nur eine einfache Annotation ohne besondere Bedeutung.

Richtig:

@SpringBootApplication kombiniert @Configuration, @EnableAutoConfiguration und @ComponentScan.

Falle 3 — Starter vs. Auto-Konfiguration

Falsch:


Ein starter erzeugt direkt Beans.

Richtig:

Ein starter bringt Dependencies. Auto-configuration erzeugt/konfiguriert Beans basierend auf diesen Dependencies.

Falle 4 — Dependency-Versionen

Falsch:


Ich sollte für jede Spring Boot Dependency manuell Versionen angeben.

Richtig:

Spring Boot dependency management liefert kompatible Versionen. Normalerweise lässt du Versionen für Boot-verwaltete Dependencies weg.

Falle 5 — JPA Starter und Database Driver

Falsch:


spring-boot-starter-data-jpa enthält automatisch den PostgreSQL Driver.

Richtig:

Der JPA starter liefert JPA- und Hibernate-Support, aber du brauchst trotzdem den Database Driver.

Beispiel:

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

Falle 6 — Auto-Konfiguration ist kein Zauber

Falsch:


Spring Boot erzeugt zufällig Beans.

Richtig:

Spring Boot nutzt Conditions basierend auf Classpath, Properties, vorhandenen Beans, Profilen und Application Type.

Falle 7 — Back-off

Falsch:


Boot erzeugt immer seine Default Bean.

Richtig:

Viele Auto-Konfigurationen backen ab, wenn du deine eigene passende Bean definierst.

Falle 8 — Component Scan vs. Auto-Konfiguration

Falsch:


Component scanning und auto-configuration sind dasselbe.

Richtig:

Component scanning findet deine annotierten Klassen.
Auto-configuration wendet Boot-Konfigurationsklassen conditional an.

Falle 9 — Actuator Exposure

Falsch:


Actuator hinzufügen exponiert alle Endpoints öffentlich.

Richtig:

Actuator-Endpoints müssen exposed werden. Sensible Endpoints solltest du absichern.

Falle 10 — YAML `*`

Falsch:

management:
  endpoints:
    web:
      exposure:
        include: *

Richtig:

management:
  endpoints:
    web:
      exposure:
        include: "*"

Falle 11 — Runners

Falsch:


CommandLineRunner und ApplicationRunner laufen, bevor Spring Beans erzeugt.

Richtig:


Runners laufen, nachdem der ApplicationContext erzeugt und refreshed wurde.

Falle 12 — CommandLineRunner vs. ApplicationRunner

CommandLineRunner bekommt rohe String-Args.
ApplicationRunner bekommt geparste ApplicationArguments.

Falle 13 — ApplicationStartedEvent vs. ApplicationReadyEvent

ApplicationStartedEvent kommt vor den Runners.
ApplicationReadyEvent kommt nach den Runners.

Falle 14 — Lazy Initialization

Falsch:


Lazy initialization verbessert nur und hat keinen Nachteil.

Richtig:

Lazy initialization kann die Startup-Zeit verbessern, aber Fehler bis zur Laufzeit verzögern.

Falle 15 — Debugging

Falsch:


Ich muss raten, warum auto-configuration passiert ist.

Richtig:

Nutze --debug, debug=true, /actuator/conditions, /actuator/beans und /actuator/configprops.

Übungsfragen

Frage 1

Was ist Spring Boot?

Antwort:

Spring Boot ist ein Projekt, das auf dem Spring Framework aufbaut und Spring-Anwendungen einfacher zu konfigurieren, zu starten, zu überwachen und zu deployen macht.

Frage 2

Welches Problem löst Spring Boot?

Antwort:

Spring Boot reduziert manuelle Konfiguration durch starter dependencies, auto-configuration, embedded server support, external configuration conventions und production-ready Features wie Actuator.

Frage 3

Was ist der Unterschied zwischen Spring Framework und Spring Boot?

Antwort:

Spring Framework liefert Kernfeatures wie IoC, dependency injection, AOP, MVC, Transactions und Data Access. Spring Boot baut auf Spring Framework auf und ergänzt auto-configuration, starters, embedded server support und production-ready Features.

Frage 4

Was enthält @SpringBootApplication?

Antwort:

@SpringBootApplication enthält:

@Configuration
@EnableAutoConfiguration
@ComponentScan

Frage 5

Was macht @EnableAutoConfiguration?

Antwort:

@EnableAutoConfiguration aktiviert Spring Boots auto-configuration-Mechanismus, der Beans basierend auf Classpath, Properties, vorhandenen Beans, Conditions, Profilen und Application Type konfiguriert.

Frage 6

Was ist ein Spring Boot starter?

Antwort:

Ein Spring Boot starter ist ein Dependency-Bundle, das gemeinsame Libraries für ein bestimmtes Feature zusammenbringt — z. B. web, JPA, security, validation, testing oder Actuator.

Frage 7

Was ist der Unterschied zwischen einem starter und auto-configuration?

Antwort:

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

Frage 8

Was ist eine transitive dependency?

Antwort:

Eine transitive dependency ist eine Dependency, die indirekt durch eine andere Dependency mitgebracht wird.

Frage 9

Was ist dependency management?

Antwort:

Dependency management heißt: ein bekanntes Set von Dependency-Versionen nutzen, damit Libraries korrekt zusammenarbeiten.

Frage 10

Warum solltest du für Boot-verwaltete Dependencies normalerweise keine Versionen angeben?

Antwort:

Weil Spring Boot dependency management kompatible Versionen für viele gängige Libraries liefert. Manuelles Überschreiben von Versionen kann Kompatibilitätsprobleme verursachen.

Frage 11

Was ist auto-configuration?

Antwort:

Auto-configuration ist Spring Boots Mechanismus, Beans automatisch zu konfigurieren — basierend auf Classpath-Dependencies, Properties, vorhandenen Beans, Conditions, Profilen und Application Type.

Frage 12

Was macht @ConditionalOnClass?

Antwort:

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

Frage 13

Was macht @ConditionalOnMissingBean?

Antwort:

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

Frage 14

Was bedeutet auto-configuration back-off?

Antwort:

Back-off heißt: Spring Boot erzeugt seine Default Bean nicht, weil der User bereits eine passende Bean bereitgestellt hat.

Frage 15

Was macht @ConditionalOnProperty?

Antwort:

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

Frage 16

Wie kannst du auto-configuration debuggen?

Antwort:

Nutze --debug, debug=true, Startup-Logs, Actuator /actuator/conditions, /actuator/beans, /actuator/configprops und Dependency-Tree-Tools.

Frage 17

Was ist Spring Boot Actuator?

Antwort:

Spring Boot Actuator liefert production-ready Monitoring- und Management-Features über operative Endpoints.

Frage 18

Was zeigt /actuator/health?

Antwort:

/actuator/health zeigt den Application-Health-Status, z. B. UP, DOWN, OUT_OF_SERVICE oder UNKNOWN.

Frage 19

Was zeigt /actuator/metrics?

Antwort:

/actuator/metrics zeigt Runtime-Metriken wie JVM Memory, HTTP Request Metrics, CPU Usage, Thread Counts und Custom Metrics.

Frage 20

Was zeigt /actuator/conditions?

Antwort:

/actuator/conditions zeigt, welche Auto-Konfigurationen gematcht haben oder nicht — und warum.

Frage 21

Was macht SpringApplication.run(...)?

Antwort:

SpringApplication.run(...) startet die Spring Boot-Anwendung, indem es den ApplicationContext erzeugt und refreshed, Konfiguration lädt, auto-configuration anwendet, Components scannt, Beans erzeugt, Dependencies injiziert, den Web Server bei Bedarf startet, Runners ausführt und Application Events published.

Frage 22

Was ist CommandLineRunner?

Antwort:

CommandLineRunner ist ein Callback-Interface, das Code nach dem Start des Application Context ausführt. Es bekommt rohe Command-Line-Argumente als String... args.

Frage 23

Was ist ApplicationRunner?

Antwort:

ApplicationRunner ist ein Callback-Interface, das Code nach dem Start des Application Context ausführt. Es bekommt geparste Argumente als ApplicationArguments.

Frage 24

Was ist ApplicationReadyEvent?

Antwort:

ApplicationReadyEvent wird published, wenn die Anwendung vollständig gestartet und bereit ist — nachdem die Runners ausgeführt wurden.

Frage 25

Was ist lazy initialization?

Antwort:

Lazy initialization heißt: Beans werden erst erzeugt, wenn sie zum ersten Mal gebraucht werden — statt eager während des Startups.

7. Mini-Mock-Prüfung — Woche 3

Anleitung

Ohne Notizen antworten.

Empfohlene Zeit:


40 Minuten

Bestehensgrenze:


80 %

40 Fragen.

Frage 1

Was ist Spring Boot?

A. Ein Ersatz für Java
B. Ein Projekt auf Basis von Spring Framework, das Konfiguration, Start, Monitoring und Deployment vereinfacht
C. Nur ein Database Framework
D. Ein Frontend Framework

Meine Antwort:

Frage 2

Welche Annotation ist der Haupteinstieg für eine Spring Boot-Anwendung?

A. @Service
B. @SpringBootApplication
C. @Entity
D. @Repository

Meine Antwort:

Frage 3

Was enthält @SpringBootApplication?

A. @Configuration, @EnableAutoConfiguration, @ComponentScan
B. @Service, @Repository, @Entity
C. @RestController, @Bean, @Table
D. @Autowired, @Transactional, @Test

Meine Antwort:

Frage 4

Was macht @ComponentScan?

A. Findet Application Components in Packages
B. Erzeugt Database Indexes
C. Führt Unit Tests aus
D. Baut Docker Images

Meine Antwort:

Frage 5

Wo scannt Spring Boot standardmäßig?

A. In jedem Package der JVM
B. Vom Package der Klasse mit @SpringBootApplication und ihren Subpackages
C. Nur aus java.lang
D. Nur aus Database Packages

Meine Antwort:

Frage 6

Was macht @EnableAutoConfiguration?

A. Aktiviert Spring Boot auto-configuration
B. Aktiviert nur JPA Repositories
C. Deaktiviert dependency injection
D. Erzeugt Frontend Components

Meine Antwort:

Frage 7

Was ist ein Spring Boot starter?

A. Ein Dependency-Bundle für ein Feature
B. Eine Controller-Methode
C. Eine SQL Migration
D. Ein Kubernetes Pod

Meine Antwort:

Frage 8

Was bringt spring-boot-starter-web normalerweise?

A. Spring MVC, embedded Tomcat, Jackson, Web Infrastructure
B. Nur PostgreSQL
C. Nur JUnit
D. Nur Flyway

Meine Antwort:

Frage 9

Was liefert spring-boot-starter-data-jpa?

A. React Components
B. JPA, Hibernate, Spring Data JPA Support
C. CSS Tools
D. Docker Registry Support

Meine Antwort:

Frage 10

Brauchst du mit dem JPA starter trotzdem einen Database Driver?

A. Ja
B. Nein
C. Nur für Frontend Apps
D. Nur für Tests

Meine Antwort:

Frage 11

Welcher starter wird häufig für Bean Validation genutzt?

A. spring-boot-starter-validation
B. spring-boot-starter-css
C. spring-boot-starter-docker
D. spring-boot-starter-clock

Meine Antwort:

Frage 12

Was kann passieren, nachdem du spring-boot-starter-security hinzufügst?

A. Endpoints können standardmäßig abgesichert werden
B. JPA wird deaktiviert
C. Die JVM fährt sofort herunter
D. YAML-Dateien werden gelöscht

Meine Antwort:

Frage 13

Was ist dependency management?

A. Manuell zufällige Versionen wählen
B. Ein kompatibles Set von Dependency-Versionen nutzen
C. Alle transitiven Dependencies entfernen
D. SQL Queries schreiben

Meine Antwort:

Frage 14

Solltest du für Boot-verwaltete Dependencies normalerweise manuell Versionen angeben?

A. Ja, immer
B. Nein, normalerweise von Spring Boot verwalten lassen
C. Nur für Controller
D. Nur für Testklassen

Meine Antwort:

Frage 15

Was ist eine transitive dependency?

A. Eine Dependency, die indirekt durch eine andere Dependency mitgebracht wird
B. Eine Dependency nur für CSS
C. Eine Dependency, die nicht heruntergeladen werden kann
D. Eine Database Row

Meine Antwort:

Frage 16

Was ist die Spring Boot BOM?

A. Bill of Materials, die Dependency-Versionen definiert
B. Ein REST Controller
C. Eine Database Migration Datei
D. Ein Logging Statement

Meine Antwort:

Frage 17

Was ist auto-configuration?

A. Manuell alle Beans erzeugen
B. Automatische conditional Konfiguration basierend auf Classpath, Properties, Beans und Conditions
C. Ein CSS Feature
D. Ein Ersatz für Java

Meine Antwort:

Frage 18

Was prüft @ConditionalOnClass?

A. Ob eine Klasse auf dem Classpath vorhanden ist
B. Ob eine Klasse nur public ist
C. Ob eine Klasse Kommentare hat
D. Ob eine Klasse in Git liegt

Meine Antwort:

Frage 19

Was macht @ConditionalOnMissingBean?

A. Erzeugt eine Bean nur, wenn noch keine passende Bean existiert
B. Löscht fehlende Beans
C. Erzeugt alle Beans doppelt
D. Startet Tomcat manuell

Meine Antwort:

Frage 20

Was bedeutet back-off?

A. Boot erzeugt seine Default Bean nicht, weil der User eine bereitgestellt hat
B. Boot stoppt das Scannen aller Klassen
C. Boot deaktiviert Java
D. Boot entfernt alle Profile

Meine Antwort:

Frage 21

Was macht @ConditionalOnProperty?

A. Wendet Konfiguration basierend auf Property-Werten an
B. Erzeugt Database Columns
C. Deaktiviert Actuator
D. Führt nur Tests aus

Meine Antwort:

Frage 22

Was ist der Unterschied zwischen component scanning und auto-configuration?

A. Kein Unterschied
B. Component scanning findet deine Klassen; auto-configuration wendet Boot-Konfiguration conditional an
C. Component scanning funktioniert nur in Frontend Apps
D. Auto-configuration funktioniert nur mit XML

Meine Antwort:

Frage 23

Wie siehst du Auto-Konfigurationsentscheidungen?

A. /actuator/conditions
B. /api/users
C. /static/index.html
D. /database/schema

Meine Antwort:

Frage 24

Was ist Spring Boot Actuator?

A. Production-ready Monitoring- und Management-Features
B. Ein Database Migration Tool
C. Ein CSS Compiler
D. Ein Frontend Router

Meine Antwort:

Frage 25

Welche Dependency fügt Actuator hinzu?

A. spring-boot-starter-actuator
B. spring-boot-starter-html
C. spring-boot-starter-git
D. spring-boot-starter-terminal

Meine Antwort:

Frage 26

Was ist der Standard-Actuator-Basispfad?

A. /actuator
B. /admin-only
C. /api
D. /spring

Meine Antwort:

Frage 27

Was zeigt /actuator/health?

A. Application Health Status
B. Alle Database Rows
C. Frontend CSS
D. Git Branches

Meine Antwort:

Frage 28

Was zeigt /actuator/metrics?

A. Runtime Metrics
B. Nur User Passwords
C. Nur Source Code
D. Nur Database Schemas

Meine Antwort:

Frage 29

Was zeigt /actuator/beans?

A. Registrierte Spring Beans
B. Browser Cookies
C. Nur Maven Repositories
D. CSS Classes

Meine Antwort:

Frage 30

Was zeigt /actuator/configprops?

A. @ConfigurationProperties Beans und gebundene Werte
B. Nur REST Responses
C. Nur SQL Indexes
D. Nur Static Files

Meine Antwort:

Frage 31

Wie exponierst du alle Actuator-Endpoints in YAML?

A. include: "*"
B. include: all-without-quotes-only
C. exposeEverything: true
D. actuator.all=true

Meine Antwort:

Frage 32

Warum sollten Actuator-Endpoints abgesichert werden?

A. Sie können sensible interne Informationen preisgeben
B. Sie sind immer öffentliche CSS Files
C. Sie löschen automatisch die Database
D. Sie deaktivieren die JVM

Meine Antwort:

Frage 33

Was macht SpringApplication.run(...)?

A. Startet die Spring Boot-Anwendung und erzeugt/refreshed den Application Context
B. Druckt nur Text
C. Kompiliert nur Java Code
D. Startet nur React

Meine Antwort:

Frage 34

Was ist CommandLineRunner?

A. Führt Startup-Code mit rohen String... args aus
B. Führt CSS Compilation aus
C. Führt nur Database Backup aus
D. Läuft vor dem Start von Java

Meine Antwort:

Frage 35

Was ist ApplicationRunner?

A. Führt Startup-Code mit geparsten ApplicationArguments aus
B. Läuft nur in Browsern
C. Führt nur SQL aus
D. Ersetzt Spring Security

Meine Antwort:

Frage 36

Wann laufen Runners?

A. Nach dem Start des Application Context
B. Vor der Java main-Methode
C. Bevor irgendeine Bean existiert
D. Nur nach dem App-Shutdown

Meine Antwort:

Frage 37

Was passiert, wenn ein Runner eine Exception wirft?

A. Der Startup schlägt normalerweise fehl
B. Es passiert nie etwas
C. Spring ignoriert es immer
D. Es wird ein HTTP 404

Meine Antwort:

Frage 38

Wann wird ApplicationReadyEvent published?

A. Nachdem die App vollständig gestartet ist und Runners gelaufen sind
B. Bevor die Environment vorbereitet wird
C. Vor der main-Methode
D. Nur beim Shutdown

Meine Antwort:

Frage 39

Was ist lazy initialization?

A. Beans werden erst erzeugt, wenn sie zum ersten Mal gebraucht werden
B. Beans werden nie erzeugt
C. Beans werden doppelt erzeugt
D. Beans werden zu JSON konvertiert

Meine Antwort:

Frage 40

Was ist ein Risiko von lazy initialization?

A. Fehler können bis zur Laufzeit verzögert werden
B. Java kann nicht kompilieren
C. Actuator wird gelöscht
D. Starters funktionieren nicht mehr

Meine Antwort:

8. Lösungen Mini-Mock-Prüfung

Lösungsschlüssel

B
B
A
A
B
A
A
A
B
A
A
A
B
B
A
A
B
A
A
A
A
B
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A

9. Punkte

Gesamtfragen: 40
Richtige Antworten:
Falsche Antworten:
Punkte:

Punkteberechnung:


richtige Antworten / 40 * 100

Beispiel:


32 / 40 * 100 = 80 %

10. Fehler-Review-Vorlage

Für jede falsche Antwort schreibst du:

## Fehler

Fragennummer:

Meine falsche Antwort:

Richtige Antwort:

Warum ich falsch lag:

Richtiges Konzept:

Merksatz:

Beispiel:

## Fehler

Fragennummer: 20

Meine falsche Antwort: B

Richtige Antwort: A

Warum ich falsch lag:
Ich dachte, back-off heißt, Boot deaktiviert auto-configuration komplett.

Richtiges Konzept:
Back-off heißt: Boot erzeugt seine Default Bean nicht, weil der User bereits eine passende Bean bereitgestellt hat.

Merksatz:
Back-off heißt: Boot tritt für meine Bean zurück.

11. Szenario-Fragen aus der Praxis

Diese Fragen sind praxisnäher und interview-ähnlich.

Szenario 1 — Web Starter fehlt

Code:

@RestController
@RequestMapping("/api/tasks")
public class TaskController {

    @GetMapping
    public List<String> tasks() {
        return List.of("A", "B");
    }
}

Aber die App exponiert keine HTTP-Endpoints.

Frage:

Was könnte fehlen?

Meine Antwort:

Musterantwort

Dem Projekt fehlt vielleicht:

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

Ohne den web starter konfiguriert Spring Boot möglicherweise weder Spring MVC noch embedded Tomcat.

Szenario 2 — JPA Starter, aber keine Database

Dependency:

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

Fehler:


Failed to configure a DataSource

Frage:

Warum?

Meine Antwort:

Musterantwort

Der JPA starter bringt JPA-/Database-bezogene Klassen auf den Classpath. Spring Boots DataSource auto-configuration matcht und versucht, eine DataSource zu konfigurieren. Wenn keine Database URL, kein Driver und keine embedded Database verfügbar ist, schlägt der Startup fehl.

Fix-Optionen:

DataSource konfigurieren
Database Driver hinzufügen
embedded Database für Tests nutzen
JPA starter entfernen, wenn nicht gebraucht
DataSourceAutoConfiguration nur excluden, wenn wirklich keine Database gebraucht wird

Szenario 3 — Security Starter Überraschung

Hinzugefügte Dependency:

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

Plötzlich brauchen Endpoints Login.

Frage:

Warum?

Meine Antwort:

Musterantwort

Spring Security liegt jetzt auf dem Classpath. Security auto-configuration matcht und wendet Default-Security-Verhalten an. Definiere eine SecurityFilterChain Bean, um Authorization Rules anzupassen.

Szenario 4 — Custom ObjectMapper

Code:

@Configuration
public class JsonConfig {

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

Frage:

Was kann mit Boots Default ObjectMapper passieren?

Meine Antwort:

Musterantwort

Wenn Boots ObjectMapper auto-configuration @ConditionalOnMissingBean nutzt, kann sie backen, weil du bereits eine ObjectMapper Bean definiert hast. Deine Bean kann Boots Default ersetzen.

Szenario 5 — Actuator Endpoint 404

Du hast hinzugefügt:

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

Aber das liefert 404:


/actuator/conditions

Frage:

Warum?

Meine Antwort:

Musterantwort

Der Endpoint ist wahrscheinlich nicht über HTTP exposed. Füge hinzu:

management:
  endpoints:
    web:
      exposure:
        include: conditions

oder expose mehrere Endpoints:

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

Szenario 6 — Gefährliche Actuator Exposure

Config:

management:
  endpoints:
    web:
      exposure:
        include: "*"

Frage:

Was ist gefährlich?

Meine Antwort:

Musterantwort

Das exponiert alle Actuator-Endpoints über HTTP. Manche Endpoints können sensible interne Informationen preisgeben — z. B. Environment Properties, configuration properties, Bean-Struktur, Mappings, Thread Dumps oder Heap Dumps. In Production nur benötigte Endpoints exposen und absichern.

Szenario 7 — Runner läuft in Production

Code:

@Component
public class SeedRunner implements CommandLineRunner {

    @Override
    public void run(String... args) {
        seedDemoData();
    }
}

Frage:

Was ist gefährlich?

Meine Antwort:

Musterantwort

Der Runner läuft bei jedem Startup in jedem Profil — auch in Production. Wenn er Daten ändert, kann das gefährlich sein. Schütze ihn mit @Profile("dev") oder @ConditionalOnProperty.

Szenario 8 — Lazy Initialization versteckt Fehler

Config:

spring:
  main:
    lazy-initialization: true

Die App startet erfolgreich, aber der erste Request schlägt fehl, weil eine Bean eine fehlende Dependency hat.

Frage:

Warum?

Meine Antwort:

Musterantwort

Lazy initialization hat die Bean-Erzeugung verzögert, bis die Bean zum ersten Mal gebraucht wurde. Die fehlende Dependency wurde nicht beim Startup entdeckt. Lazy initialization kann den Startup beschleunigen, aber Fehler bis zur Laufzeit verzögern.

12. Mündliche Abschlussprüfung — Woche 3

Diese Fragen laut beantworten.

Frage 1

Erkläre, was Spring Boot ist.

Frage 2

Erkläre @SpringBootApplication.

Frage 3

Erkläre den Unterschied zwischen Spring Framework und Spring Boot.

Frage 4

Erkläre Spring Boot starters.

Frage 5

Erkläre dependency management.

Frage 6

Erkläre auto-configuration.

Frage 7

Erkläre auto-configuration back-off.

Frage 8

Erkläre, wie du auto-configuration debuggst.

Frage 9

Erkläre Spring Boot Actuator.

Frage 10

Erkläre SpringApplication.run.

Frage 11

Erkläre CommandLineRunner vs. ApplicationRunner.

Frage 12

Erkläre lazy initialization.

13. Gute mündliche Antworten

Mündliche Antwort 1 — Spring Boot

Spring Boot ist ein Projekt, das auf dem Spring Framework aufbaut. Es macht Spring-Anwendungen einfacher zu konfigurieren, zu starten, zu überwachen und zu deployen. Es liefert starter dependencies, auto-configuration, embedded server support, external configuration conventions und production-ready Features wie Actuator. Es ersetzt Spring Framework nicht — es nutzt es.

Mündliche Antwort 2 — `@SpringBootApplication`

@SpringBootApplication ist die Hauptannotation für eine Spring Boot-Anwendung. Sie kombiniert @Configuration, @EnableAutoConfiguration und @ComponentScan. @Configuration erlaubt Bean-Definitionen, @EnableAutoConfiguration aktiviert Boots conditional auto-configuration, und @ComponentScan scannt das aktuelle Package und Subpackages nach Components.

Mündliche Antwort 3 — Spring Framework vs. Spring Boot

Spring Framework liefert die Kernfeatures wie IoC, dependency injection, AOP, MVC, Transactions und Data Access. Spring Boot baut auf Spring Framework auf und ergänzt Convenience-Features wie starters, auto-configuration, embedded server support, external configuration conventions und Actuator.

Mündliche Antwort 4 — Starters

Spring Boot starters sind Dependency-Bundles. Sie bringen gemeinsame Libraries für ein bestimmtes Feature. Zum Beispiel bringt spring-boot-starter-web Spring MVC, embedded Tomcat, Jackson und Web-Infrastructure-Dependencies. Starters reduzieren Dependency-Boilerplate und arbeiten mit auto-configuration zusammen.

Mündliche Antwort 5 — Dependency Management

Spring Boot dependency management liefert ein kompatibles Set von Dependency-Versionen. Das heißt: Normalerweise gibst du für Boot-verwaltete Dependencies keine Versionen manuell an. Boot wählt Versionen, die gut zusammenarbeiten — und reduziert Runtime-Fehler wie NoSuchMethodError, ClassNotFoundException oder Dependency-Konflikte.

Mündliche Antwort 6 — Auto-Konfiguration

Auto-configuration ist Spring Boots Mechanismus, Beans automatisch zu konfigurieren — basierend auf Classpath-Dependencies, Application Properties, vorhandenen Beans, aktiven Profilen, Application Type und Conditions. Es ist kein Zauber; es ist conditional Konfiguration. Wenn Spring MVC und Tomcat auf dem Classpath liegen, kann Boot z. B. eine Servlet Web Application konfigurieren.

Mündliche Antwort 7 — Back-off

Back-off heißt: Spring Boot erzeugt seine Default Bean nicht, weil du bereits eine passende Bean definiert hast. Das wird häufig mit @ConditionalOnMissingBean umgesetzt. So liefert Boot Defaults, während Entwickler die Anwendung trotzdem anpassen können.

Mündliche Antwort 8 — Auto-Konfiguration debuggen

Zum Debuggen von auto-configuration prüfst du Dependencies, aktive Profile, Properties und vorhandene Beans. Du kannst die App mit --debug oder debug=true starten, um Condition-Evaluation-Logs zu sehen. Mit Actuator nutzt du /actuator/conditions für Auto-Konfigurations-Matches, /actuator/beans für registrierte Beans und /actuator/configprops für gebundene configuration properties.

Mündliche Antwort 9 — Actuator

Spring Boot Actuator liefert production-ready Monitoring- und Management-Features. Es exponiert operative Endpoints wie /actuator/health, /actuator/info, /actuator/metrics, /actuator/beans, /actuator/conditions und /actuator/configprops. Diese Endpoints helfen, die Anwendung zu überwachen und Runtime-Konfiguration zu debuggen. Sensible Endpoints solltest du absichern und nicht öffentlich exposen.

Mündliche Antwort 10 — `SpringApplication.run`

SpringApplication.run startet die Spring Boot-Anwendung. Es bereitet die Environment vor, lädt Konfiguration, erzeugt und refreshed den ApplicationContext, wendet auto-configuration an, scannt Components, erzeugt Beans, injiziert Dependencies, führt Lifecycle Callbacks aus, startet den embedded Server bei Bedarf, führt Startup Runners aus und published Application Events.

Mündliche Antwort 11 — `CommandLineRunner` vs. `ApplicationRunner`

Beide laufen nach dem Start des Application Context. CommandLineRunner bekommt rohe Command-Line-Argumente als String... args. ApplicationRunner bekommt geparste Argumente als ApplicationArguments Objekt. Nutze ApplicationRunner, wenn du strukturierte Option- und Non-Option-Argumente brauchst.

Mündliche Antwort 12 — Lazy Initialization

Lazy initialization heißt: Spring erzeugt Beans erst, wenn sie zum ersten Mal gebraucht werden — statt eager während des Startups. Das kann die Startup-Zeit verbessern und Memory Usage beim Startup reduzieren, kann aber auch Fehler bis zur Laufzeit verzögern. Eine fehlende Dependency in einer lazy Bean taucht z. B. erst beim ersten Request auf, der diese Bean nutzt.

14. Readiness-Checkliste Woche 3

Bevor du zu Woche 4 weitergehst, solltest du alles Folgende abhaken können:

[ ] Ich kann erklären, was Spring Boot ist.
[ ] Ich kann Spring Framework und Spring Boot vergleichen.
[ ] Ich weiß, was @SpringBootApplication enthält.
[ ] Ich kann @Configuration erklären.
[ ] Ich kann @EnableAutoConfiguration erklären.
[ ] Ich kann @ComponentScan erklären.
[ ] Ich weiß, wo Spring Boot standardmäßig scannt.
[ ] Ich weiß, warum die Main Class im Root Package liegen sollte.
[ ] Ich kann starters erklären.
[ ] Ich kann dependency management erklären.
[ ] Ich kann transitive dependencies erklären.
[ ] Ich weiß, warum Versionen normalerweise weggelassen werden.
[ ] Ich weiß, was die Spring Boot BOM ist.
[ ] Ich weiß, was spring-boot-starter-web liefert.
[ ] Ich weiß, was spring-boot-starter-data-jpa liefert.
[ ] Ich weiß, dass JPA trotzdem einen Database Driver braucht.
[ ] Ich weiß, dass validation oft spring-boot-starter-validation braucht.
[ ] Ich weiß, dass der security starter Endpoints absichern kann.
[ ] Ich kann auto-configuration erklären.
[ ] Ich kann Conditions erklären.
[ ] Ich kann @ConditionalOnClass erklären.
[ ] Ich kann @ConditionalOnMissingBean erklären.
[ ] Ich kann @ConditionalOnProperty erklären.
[ ] Ich kann back-off erklären.
[ ] Ich kann component scanning und auto-configuration vergleichen.
[ ] Ich kann auto-configuration mit --debug und Actuator debuggen.
[ ] Ich kann Actuator erklären.
[ ] Ich kenne gängige Actuator-Endpoints.
[ ] Ich kann health, info, metrics, beans, conditions, configprops erklären.
[ ] Ich weiß, dass Actuator-Endpoints abgesichert werden sollten.
[ ] Ich kann SpringApplication.run erklären.
[ ] Ich kann den Startup-Flow erklären.
[ ] Ich kann CommandLineRunner erklären.
[ ] Ich kann ApplicationRunner erklären.
[ ] Ich weiß, dass Runners nach dem Context-Startup laufen.
[ ] Ich kann ApplicationReadyEvent erklären.
[ ] Ich kann lazy initialization erklären.
[ ] Ich weiß, dass lazy initialization Fehler verzögern kann.

15. Schwache Themen vor Woche 4

Schwache Themen hier eintragen:

## Meine Schwachstellen







Für jedes schwache Thema:

## Schwachstelle

Thema:

Warum es verwirrend ist:

Richtige Erklärung:

Code-Beispiel:

Merksatz:

16. Abschluss-Zusammenfassung Woche 3

Woche 3 hat dir gezeigt, wie Spring Boot Spring einfacher macht.

Die wichtigste Idee:

Spring Boot ist Spring plus Conventions, starters, auto-configuration, Monitoring und einfacherem Startup.

Spring Boot startet mit:

@SpringBootApplication

was enthält:

@Configuration
@EnableAutoConfiguration
@ComponentScan

Starters:


bringen Dependencies

Auto-configuration:


konfiguriert Beans conditional

Actuator:


zeigt operative Informationen über eine laufende App

Startup runners:


führen Code nach dem Start des Application Context aus

Lazy initialization:


erzeugt Beans erst, wenn sie zum ersten Mal gebraucht werden

Wenn du Woche 3 gut verstanden hast, bist du bereit für Woche 4:


Spring MVC und REST APIs

Ziel​

1. Das große Bild aus Woche 3​

2. Zentrale Merksätze​

3. Concept Map​

4. Wichtigste Prüfungsfallen​

Falle 1 — Spring vs. Spring Boot​

Falle 2 — @SpringBootApplication​

Falle 3 — Starter vs. Auto-Konfiguration​

Falle 4 — Dependency-Versionen​

Falle 5 — JPA Starter und Database Driver​

Falle 6 — Auto-Konfiguration ist kein Zauber​

Falle 7 — Back-off​

Falle 8 — Component Scan vs. Auto-Konfiguration​

Falle 9 — Actuator Exposure​

Falle 10 — YAML *​

Falle 11 — Runners​

Falle 12 — CommandLineRunner vs. ApplicationRunner​

Falle 13 — ApplicationStartedEvent vs. ApplicationReadyEvent​

Falle 14 — Lazy Initialization​

Falle 15 — Debugging​

Übungsfragen​

Frage 1​

Frage 2​

Frage 3​

Frage 4​

Frage 5​

Frage 6​

Frage 7​

Frage 8​

Frage 9​

Frage 10​

Frage 11​

Frage 12​

Frage 13​

Frage 14​

Frage 15​

Frage 16​

Frage 17​

Frage 18​

Frage 19​

Frage 20​

Frage 21​

Frage 22​

Frage 23​

Frage 24​

Frage 25​

7. Mini-Mock-Prüfung — Woche 3​

Anleitung​

Frage 1​

Frage 2​

Frage 3​

Frage 4​

Frage 5​

Frage 6​

Frage 7​

Frage 8​

Frage 9​

Frage 10​

Frage 11​

Frage 12​

Frage 13​

Frage 14​

Frage 15​

Frage 16​

Frage 17​

Frage 18​

Frage 19​

Frage 20​

Frage 21​

Frage 22​

Frage 23​

Frage 24​

Frage 25​

Frage 26​

Frage 27​

Frage 28​

Frage 29​

Frage 30​

Frage 31​

Frage 32​

Ziel

1. Das große Bild aus Woche 3

2. Zentrale Merksätze

3. Concept Map

4. Wichtigste Prüfungsfallen

Falle 1 — Spring vs. Spring Boot

Falle 2 — `@SpringBootApplication`

Falle 3 — Starter vs. Auto-Konfiguration

Falle 4 — Dependency-Versionen

Falle 5 — JPA Starter und Database Driver

Falle 6 — Auto-Konfiguration ist kein Zauber

Falle 7 — Back-off

Falle 8 — Component Scan vs. Auto-Konfiguration

Falle 9 — Actuator Exposure

Falle 10 — YAML `*`

Falle 11 — Runners

Falle 12 — CommandLineRunner vs. ApplicationRunner

Falle 13 — ApplicationStartedEvent vs. ApplicationReadyEvent

Falle 14 — Lazy Initialization

Falle 15 — Debugging

Übungsfragen

Frage 1

Frage 2

Frage 3

Frage 4

Frage 5

Frage 6

Frage 7

Frage 8

Frage 9

Frage 10

Frage 11

Frage 12

Frage 13

Frage 14

Frage 15

Frage 16

Frage 17

Frage 18

Frage 19

Frage 20

Frage 21

Frage 22

Frage 23

Frage 24

Frage 25

7. Mini-Mock-Prüfung — Woche 3

Anleitung

Frage 1

Frage 2

Frage 3

Frage 4

Frage 5

Frage 6

Frage 7

Frage 8

Frage 9

Frage 10

Frage 11

Frage 12

Frage 13

Frage 14

Frage 15

Frage 16

Frage 17

Frage 18

Frage 19

Frage 20

Frage 21

Frage 22

Frage 23

Frage 24

Frage 25

Frage 26

Frage 27

Frage 28

Frage 29

Frage 30

Frage 31

Frage 32