Spring Integration - Logging

[niceWork]

Hi @all!

Ich bin auf der Suche nach einem sehr "speziellen" Lösungsansatz.
Es geht um ein bestehendes Projekt, in welchem wir mit Spring Integration arbeiten. Wir loggen in diesem Tool einiges mit, um gut debuggen zu können. Eine solche Log-Zeile könnte z. B. so aussehen:

2022-06-14 13:32:46.659 DEBUG 8 --- [eResolution-325] ionFlow$$EnhancerBySpringCGLIB$$f7eeb538 : GenericMessage [payload=xxxxx......

Wie man in diesem Beispiel sieht, ist die ausführende Klasse durch "ionFlow$$Enhancer... " maskiert, das erschwert die Lesbarkeit und ist für mich kontraproduktiv. Jetzt würde mich interessieren, ob es eine Möglichkeit gibt, das zu ersetzen?

Im Flow wird folgende Logzeile mehrmals verwendet, diese müsste daran "schuld" sein:

.log(DEBUG, getClass().getName())

Ich glaube, das liegt am Methodenaufruf Ich glaube, das liegt am Methodenaufruf

getClass().getName()

zur Laufzeit, dass da irgendwelche interne Proxies o. ä. "reinpfuschen". zur Laufzeit, dass da irgendwelche interne Proxies o. ä. "reinpfuschen".

Freue mich auf eure Antworten!

Besten Dank und LG

Edit: Falsche Formatierung von Code behoben

 

[Robert Zenz]

Ohne jetzt zu wissen was genau du tust, aber waere das anlegen einer statischen Logger Instanz nicht die Loesung?

// Pseudo-Code weil zu faul um nachzuschauen:
private static final Logger LOGGER = LoggerFactory.newInstance(MyCoolClass.class);

Dann hast du den Logger an deine Klasse gebunden, nicht an die welche es zur Laufzeit wird durch Spring.

 

[niceWork]

Danke Robert für die schnelle Antwort!
Das Problem ist noch etwas komplexer. Ich habe mittlerweile rausgefunden, dass man der log-Methode als zweiten Parameter einfach einen String übergeben kann, der dann den Klassennamen im Logging definiert. Würde soweit funktionieren:

private static final String LOGGING_CLASS_NAME = xxx.class.getName();
// ....
.log(DEBUG, LOGGING_CLASS_NAME);

Jetzt möchte ich das noch "eskalieren" - alle Flows leiten von einem Interface ab. In diesem hätte ich gerne eine default Methode die den statischen Namen der aktuellen Klasse zurückgibt. Wie könnte ich das am besten anstellen, dass ich den aktuellen Klassenname wo die Methode aufgerufen wird nehme und dann statisch zurückgebe?

 

[KonradN]

In der default Methode kannst Du doch auf this zugreifen, also kannst Du etwas machen wie this.getClass().getName() um an den Namen der Klasse zu kommen.

 

[Robert Zenz]

Wie könnte ich das am besten anstellen, dass ich den aktuellen Klassenname wo die Methode aufgerufen wird nehme und dann statisch zurückgebe?

Gar nicht. Entweder du holst den Namen zur Kompilierung (MyService.class.getName()), oder du holst ihn zur Laufzeit (this.getClass().getName()). Deine Schnittstelle kann nur letzteres, weil sie nichts von an den ableitenden Klassen weisz, und zur Laufzeit ist es die Spring-Klasse.

Deine Loesung waere schon die beste, aber idealerweise hast du eine Logger-Klasse welche es dir erlaubt nicht jedesmal den Klassennamen angeben zu muessen, sondern nur einmal, wie in meinem Beispiel.

 

[Robert Zenz]

Nein, ist gelogen. Du kannst dir natuerlich Logik schreiben welche die Basisklassen sucht im Klassen-Baum. Etwas Pseudo-Code:

private Class<?> getWantedParentClass() {
    Class<?> currentClass = this.getClass();
    
    while (currentClass != null) {
        if (matchesWantedCriteria(currentClass)) {
            return currentClass;
        }
        
        currentClass = currentClass.getParent();
    }
    
    // Fallback
    return this.getClass();
}

Dann musst du nur definieren was "deine" Klassen sind welche du willst. Also du gehst den Ableitungsbaum von den Spring-Klassen abwaerts bis du deine Klasse findest welche du fuer das Logging verwenden willst.

 

[LimDul]

Die Idee ging mir beim lesen auch durch den Kopf, aber die hat für mich einen größeren Kritikpunkt. Im Fehlerfall, wenn das Logging aufgerufen wird, wird damit eine Menge Logik ausgeführt um den Fehler zu protokollieren. Wenn diese Logik Fehler hat, ist das sehr unschön. Logging sollte so simpel wie möglich sein und so robust wie möglich - eine Exception im catch Block beim loggen ist (wenn man sie nicht explizit behandelt) so ziemlich der Worst Case bzgl. der Nachvollziehbarkeit, weil dann der ursprüngliche Fehler komplett geschluckt wird.

 

[Robert Zenz]

Im Fehlerfall, wenn das Logging aufgerufen wird, wird damit eine Menge Logik ausgeführt um den Fehler zu protokollieren.

Deswegen der Rueckfall auf die aktuelle Klasse, und idealerweise macht man das nur einmal und speichert das Ergebnis irgendwo. Aber klar, mein Beispiel war bei weitem nicht vollstaendig in der Hinsicht.