23 Auto-Configuration und Embedded Server

Zwei Features machen Spring Boot so produktiv: Auto-Configuration erkennt, was du brauchst. Der Embedded Server macht Deployment trivial. Ein kurzer Überblick über beide.

23.1 Auto-Configuration im Überblick

Spring Boot schaut beim Start in den Classpath. Basierend auf dem, was es findet, trifft es Konfigurationsentscheidungen.

Das Prinzip: Wenn eine Bibliothek da ist, wird sie vermutlich gebraucht. Also konfiguriere sie mit sinnvollen Defaults.

23.2 Wie es funktioniert

Unter der Haube arbeiten @Conditional-Annotationen:

// Vereinfachtes Beispiel - so sieht Auto-Configuration intern aus
@Configuration
@ConditionalOnClass(MongoClient.class)  // Nur wenn MongoDB-Driver im Classpath
@ConditionalOnMissingBean(MongoClient.class)  // Nur wenn nicht manuell konfiguriert
public class MongoAutoConfiguration {
    
    @Bean
    public MongoClient mongoClient(MongoProperties properties) {
        return MongoClients.create(properties.getUri());
    }
}

Die Bedingungen stellen sicher:

  1. Die Bibliothek ist vorhanden (sonst macht Konfiguration keinen Sinn)
  2. Du hast nicht selbst konfiguriert (sonst würde Spring Boot überschreiben)

23.3 Was Auto-Configuration nicht kann

Auto-Configuration ist schlau, aber nicht allwissend. Sie kann erkennen, dass MongoDB im Classpath liegt. Sie kann nicht erraten, wo dein MongoDB-Server läuft.

Technische Verdrahtung: automatisch. Umgebungsspezifische Details: manuell.

# Das musst du selbst konfigurieren
spring:
  data:
    mongodb:
      uri: mongodb://user:pass@server:27017/arcade

23.4 Der Embedded Server

Traditionell brauchtest du einen Application Server: Tomcat installieren, WAR-Datei deployen, Server konfigurieren. Spring Boot dreht das um.

Der Server ist Teil deiner Anwendung. Er startet mit ihr, stoppt mit ihr. Kein externes Management nötig.

23.5 Welcher Server?

Spring Boot unterstützt mehrere Embedded Server:

Server Starter Anwendungsfall
Tomcat Default in starter-web Standard für Servlet-Apps
Jetty spring-boot-starter-jetty Leichtgewichtig
Undertow spring-boot-starter-undertow Performance-kritisch
Netty Default in starter-webflux Reactive Apps

Tomcat ist der Default. Für die meisten Anwendungen perfekt.

Wechsel zu Jetty:

// build.gradle.kts
dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web") {
        exclude(group = "org.springframework.boot", module = "spring-boot-starter-tomcat")
    }
    implementation("org.springframework.boot:spring-boot-starter-jetty")
}

23.6 Server-Konfiguration

Der Embedded Server ist konfigurierbar wie ein externer:

server:
  port: 8080
  
  # Thread-Pool
  tomcat:
    threads:
      max: 200
      min-spare: 10
    
  # Timeouts
  connection-timeout: 5000
  
  # Kompression
  compression:
    enabled: true
    mime-types: text/html,application/json
    min-response-size: 1024

Für Entwicklung reichen die Defaults. Für Produktion lohnt sich Feintuning.

23.7 Das JAR ist alles

Nach dem Build hast du ein “Fat JAR” – eine Datei, die alles enthält:

./gradlew build
ls build/libs/
# arcade-highscore-api-0.0.1-SNAPSHOT.jar

Diese eine Datei enthält:

Deployment bedeutet: Datei kopieren, starten.

java -jar arcade-highscore-api-0.0.1-SNAPSHOT.jar

Keine Umgebung vorbereiten, keine Server installieren, keine Deploymentprozesse. Einfach starten.

23.8 Wann kein Embedded Server?

Es gibt Situationen, in denen externe Server sinnvoll sind:

Für diese Fälle kann Spring Boot WAR-Dateien erzeugen. Aber das ist die Ausnahme, nicht die Regel.

23.9 Das Zusammenspiel

Auto-Configuration und Embedded Server arbeiten zusammen:

Du fügst spring-boot-starter-web hinzu. Auto-Configuration erkennt Tomcat im Classpath, konfiguriert ihn, startet ihn. Du schreibst einen Controller, er beantwortet Requests. Die Infrastruktur ist unsichtbar.

Das ist das Versprechen von Spring Boot: Du konzentrierst dich auf deine Anwendung. Das Framework kümmert sich um den Rest.