Zwei Features machen Spring Boot so produktiv: Auto-Configuration erkennt, was du brauchst. Der Embedded Server macht Deployment trivial. Ein kurzer Überblick über beide.
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.
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:
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/arcadeTraditionell 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.
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")
}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: 1024Für Entwicklung reichen die Defaults. Für Produktion lohnt sich Feintuning.
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.jarDiese eine Datei enthält:
Deployment bedeutet: Datei kopieren, starten.
java -jar arcade-highscore-api-0.0.1-SNAPSHOT.jarKeine Umgebung vorbereiten, keine Server installieren, keine Deploymentprozesse. Einfach starten.
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.
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.