Kapitel 28 · Tools

Spring Shell für interne CLI-Werkzeuge

Typ: FrameworkVersion 2 ausführlich

Spring Shell ermöglicht interaktive Kommandozeilenanwendungen mit Spring Beans, Commands, Validierung und Autovervollständigung.

‹ Zurück ⌂ Index Weiter ›

Fachliche Einordnung

Enterprise-Teams brauchen oft Admin-, Migrations-, Diagnose- oder Support-Tools. Eine CLI kann sicherer und reproduzierbarer sein als manuelle Datenbankeingriffe.

Enterprise-Merksatz: Spring Shell ermöglicht interaktive Kommandozeilenanwendungen mit Spring Beans, Commands, Validierung und Autovervollständigung.

Technische Darstellung

Kernkonzepte

@ShellComponent und @ShellMethod.
Command Parameter Binding und Validation.
Wiederverwendung von Application Services.
Profile für Admin/Support-Werkzeuge.
Audit und Berechtigungen nicht vergessen.

Wann einsetzen?

Du brauchst kontrollierte interne Wartungsbefehle.
Du migrierst Shell-/SQL-Skripte in eine geprüfte Anwendung.
Du willst Diagnosefunktionen für Supportteams bereitstellen.

Typische Fehler und Risiken

CLI umgeht Fachservices und schreibt direkt in Tabellen.
Keine Audit Logs.
Produktionsbefehle ohne Confirmation oder Dry Run.

Legacy- und Modernisierungssicht

Alte Admin-Skripte werden zu Spring Shell Commands, die dieselben Use Cases wie die Anwendung verwenden.

Ausführliches Beispiel

Das Beispiel zeigt bewusst nicht nur Annotationen, sondern auch die Verantwortung der Schicht. In echten Projekten sollte der technische Spring-Code an Adapter- oder Konfigurationsrändern bleiben, während die Fachlogik testbar und möglichst frameworkarm bleibt.

@ShellComponent
class OrderMaintenanceCommands {
    private final OrderRepairService repairService;

    @ShellMethod(key = "order-repair", value = "Repariert inkonsistente Aufträge nach geprüfter Regel")
    String repair(@ShellOption UUID orderId, @ShellOption(defaultValue = "false") boolean dryRun) {
        RepairReport report = repairService.repair(orderId, dryRun);
        return report.toHumanReadableText();
    }
}

Checkliste für Reviews

Ist die Verantwortung des Bausteins klar: Framework steuert Lebenszyklus, Library wird gezielt benutzt?
Ist die Fachlogik außerhalb von Controller, Listener, Repository-Implementierung oder Konfiguration?
Sind Fehlerfälle, Timeouts, Security, Monitoring und Tests sichtbar modelliert?
Gibt es klare Grenzen zwischen DTO, Domäne, Persistence und Infrastruktur?