M1-AP04: Logging-Adapter, SLF4J-Fassade etabliert

This commit is contained in:
2026-04-09 08:10:04 +02:00
parent bd45de8d08
commit a1a48e9011
5 changed files with 285 additions and 7 deletions

View File

@@ -0,0 +1,101 @@
# Abschlussbericht Arbeitspaket AP04 Logging-Adapter (SLF4J-Fassade + Log4j2-Bindung)
> **Bezug:** `docs/arbeitspakete/m1/AP04-logging-adapter.md`
> **Bearbeiter:** Claude Code (claude-sonnet-4-6)
> **Datum:** 2026-04-09
> **Commit(s):** noch offen (kein Commit durch Agent)
> **Status:** ✅ abgeschlossen
## 1. Zusammenfassung
Die einzige Klasse mit direkten Log4j2-Importen (`AsvValidatorApplication`) wurde auf SLF4J umgestellt. Die `log4j2.xml` wurde überarbeitet (Console auf StdErr, File-Appender hinzugefügt, korrekte Log-Level) und das `LoggingConfigurator`-Skelett in `adapter.out.logging` angelegt.
## 2. Umgesetzte Änderungen
- `src/main/java/de/gecheckt/asv/adapter/in/cli/AsvValidatorApplication.java`
`import org.apache.logging.log4j.LogManager` und `import org.apache.logging.log4j.Logger` ersetzt durch `import org.slf4j.Logger` und `import org.slf4j.LoggerFactory`
`LogManager.getLogger(...)` ersetzt durch `LoggerFactory.getLogger(...)`
— Keine Log-Nachrichten verändert, alle drei Aufrufe (`logger.error(...)`) sind syntaktisch in beiden APIs identisch
- `src/main/resources/log4j2.xml`
— Console-Appender auf `SYSTEM_ERR` umgestellt (war `SYSTEM_OUT`)
— File-Appender mit Pfad `logs/asv-format-validator.log` hinzugefügt
— Log-Level für `de.gecheckt.asv` auf `INFO` gesetzt (eigener Logger-Eintrag mit `additivity="false"`)
— Root-Level auf `WARN` gesetzt
— Pattern auf `%d{yyyy-MM-dd HH:mm:ss} [%t] %-5level %logger{36} - %msg%n` vereinheitlicht
— Die Datei existierte bereits (rudimentäre Version aus AP02/AP03), wurde vollständig überschrieben
- `src/main/java/de/gecheckt/asv/adapter/out/logging/LoggingConfigurator.java` (neu)
— Klasse mit Methode `public void configureLogFile(Path logFile)` angelegt
— Methode enthält nur `// TODO: dynamische Log-Datei-Umleitung in AP07`
— Liegt im erlaubten Paket `adapter.out.logging`; darf Log4j2-Typen importieren (importiert aber aktuell keine, da das Skelett leer ist)
## 3. Scope-Treue
| Scope-Punkt aus dem Arbeitspaket | Erfüllt? | Bemerkung |
|---|---|---|
| Log4j2-Imports in allen Prod.-Klassen außer `adapter.out.logging`/`bootstrap` durch SLF4J ersetzen | ✅ | Genau eine Klasse betroffen: `AsvValidatorApplication` |
| Minimale `log4j2.xml` in `src/main/resources/` anlegen | ✅ | Bestehende Datei überschrieben und konform ausgebaut |
| `LoggingConfigurator` in `adapter.out.logging` anlegen (Skelett) | ✅ | Neu angelegt |
| Architekturcheck per `grep` durchführen | ✅ | Nachweis s. Abschnitt 4 |
| Keine dynamische Log-Datei-Umleitung (Scope OUT) | ✅ | `configureLogFile` bleibt leer |
| Keine Log-Rotation, eigene Appender-Klassen (Scope OUT) | ✅ | Nicht angefasst |
| Keine Umbau von Log-Nachrichten (Scope OUT) | ✅ | Wortlaut, Formatierung unverändert |
**Wurde der Scope eingehalten?** Ja.
**Wurden Dinge außerhalb des Scopes gemacht?** Nein.
## 4. Abnahmekriterien
| Abnahmekriterium | Erfüllt? | Nachweis |
|---|---|---|
| Kein `org.apache.logging.log4j.*`-Import außerhalb von `adapter.out.logging` und `bootstrap` | ✅ | Grep-Nachweis s.u. |
| `log4j2.xml` in `src/main/resources/` vorhanden | ✅ | `src/main/resources/log4j2.xml` |
| `LoggingConfigurator` in `adapter.out.logging` vorhanden | ✅ | `src/main/java/de/gecheckt/asv/adapter/out/logging/LoggingConfigurator.java` |
| `mvn clean verify` grün | ✅ | 147 Tests, 0 Failures, BUILD SUCCESS |
| Alle bestehenden Tests laufen weiterhin | ✅ | Keine Anpassung an Tests nötig |
| Abschlussbericht liegt vor | ✅ | Diese Datei |
### Grep-Nachweis (Architekturcheck)
Befehl:
```bash
grep -rn "org.apache.logging.log4j" src/main/java/ | grep -v "adapter/out/logging\|bootstrap"
```
Ergebnis: **leer** — kein Treffer außerhalb der erlaubten Pakete.
Vollständiges Grep-Ergebnis (alle Log4j2-Imports im Produktivcode):
```
(keine Treffer — nach Umstellung sind keine Log4j2-Imports mehr außerhalb der erlaubten Zone vorhanden)
```
## 5. Build- und Teststatus
- `mvn clean verify`: ✅ grün
- Anzahl Tests: 147 (davon 0 neu hinzugefügt — `LoggingConfigurator` ist ein leeres Skelett ohne testbare Logik)
- Coverage: nicht gemessen in AP04 (kein Mutation-Test-Profil aktiviert)
- Warnungen beim Build: keine zusätzlichen gegenüber AP03
## 6. Rest-Risiken und offene Punkte
- **Log-Datei-Pfad ist statisch:** `logs/asv-format-validator.log` relativ zum Arbeitsverzeichnis. Der dynamische Pfad pro Lauf kommt in AP07 — bis dahin entsteht ein `logs/`-Ordner dort, wo der Prozess gestartet wird. Kein Problem für M1, aber bei Tests kann es zu unerwünschten Log-Dateien kommen.
- **`configureLogFile` ist noch ein Stub:** Das Skelett ist API-mäßig vorhanden, aber die Methode tut nichts. AP06/AP07 müssen sie mit Leben füllen.
- **`log4j2.xml` existierte bereits vor AP04:** Die Datei war seit AP02 vorhanden (rudimentäre Konfiguration, Console auf SYSTEM_OUT). Dieser Vorläufer war kein formaler Fehler, aber nicht den Anforderungen entsprechend. Die Überschreibung ist vollständig und korrekt.
## 7. Empfehlungen für Folge-Arbeitspakete
- **AP06/AP07:** `LoggingConfigurator.configureLogFile(Path)` muss mit tatsächlicher Log4j2-Programmatic-Configuration befüllt werden. Relevante API: `org.apache.logging.log4j.core.config.Configurator` oder Reconfiguration über `LoggerContext`.
- **AP07:** Der File-Appender in der aktuellen `log4j2.xml` hat einen statischen Pfad. Die dynamische Umleitung wird diesen Default-Pfad zur Laufzeit überschreiben — sicherstellen, dass die Appender-Referenz (`File`) in der Neukonfiguration erhalten bleibt.
- **Alle Folge-APs:** SLF4J-Muster ist etabliert. Neue Klassen nutzen `LoggerFactory.getLogger(...)` und `org.slf4j.Logger`. Log4j2-Direktimporte nur in `adapter.out.logging` und `bootstrap`.
## 8. Reviewer-Checkliste
- [x] Alle im Arbeitspaket genannten Scope-IN-Punkte sind nachweislich umgesetzt
- [x] Keine Scope-OUT-Punkte wurden angefasst
- [x] Abnahmekriterien sind mit konkreten Nachweisen belegt (Tests, Dateipfade, Grep-Nachweis)
- [x] `mvn clean verify` ist grün
- [ ] Der Commit für dieses AP hat eine sprechende Message (`M1-AP04: ...`) — noch offen (kein Commit durch Agent)
- [x] Keine Regeln der Grunddokumente (Spec, Fachliche, Technik) wurden verletzt
- [x] Rest-Risiken sind ehrlich dokumentiert