Google Guice AOP + Logging

[DamienX]

Hallo zusammen,

ich setz mich grad mit Google Guice auseinander und fand die Vorstellung recht
nett das Logging einen Guice MehtodInterceptor zu überlassen.

Das Problem dass sich mir stellt ist die Tatsache dass ich Logging nur über
den klassischen statischen Logger kenne.

JPseudocode:

public class SomeClazz{
     private static final Logger logger = Logger.getLogger(SomeClazz.class);
    

     public void aMethod(){
          logger.trace(..."call");
          
          try{
               oject.callSomething();
          }catch (WtfIsHappeningExepction ex) {
              logger.warning(... ex-infos);   
          }

           logger.trace(..."called");
     }
     ....
}

Die nummer mit nem Interceptor zu lösen erscheint mir mehr als angebracht.

Ich habe mir also einen geschrieben und der sieht voerst folgendermaßen aus...

import java.lang.reflect.Method;

import org.aopalliance.intercept.MethodInterceptor;
import org.aopalliance.intercept.MethodInvocation;
import org.apache.log4j.Logger;

@Override
	public Object invoke(MethodInvocation invocation) throws Throwable {
		Object o = null;
		
		//get invoking method
		Method invokingMethod = invocation.getMethod();
		
		//get declaring class of the method
		Class<?> clazz = invocation.getMethod().getDeclaringClass();
		
		//get a logger for this class
		Logger logger = Logger.getLogger(clazz);
		
		// for tracing level
		logger.trace(" call... " + invokingMethod.getName());
		
		try{
			o = invocation.proceed();
		} catch (Exception e){
			logger.warn(e.toString());
			throw e;
		}
		
		logger.trace(invokingMethod.getName() +" ...called.");
		
		return o;
	}

Dieser wird an eine Annotation gebunden...

Sollten nun in einer Methode nur Exceptions geloggt werden reicht dieser Interceptor
vollkommen aus. Bei loggings von anderen Geschichten (erfolgreiche Transaktionen etc. ) welche
dieser Interceptor nicht abdecken kann, könnte man dann ja wieder auf den guten alten
statischen logger zurückgreifen.

Aber ne Menge schreibarbeit wäre schon mal gespart.
Nun zu den eigentlichen Fragen:

1. Kann ich beim holen des Loggers via Logger logger = Logger.getLogger(clazz);
probleme kriegen?
2. Die Performanceeinbuse scheint verkraftbar zu sein (Abweichung ca. 5% bei abertausenden
aufrufen) wenn man bedenkt dass nicht jede Methode mitgeloggt werden muss...
oder hat hier jmd andere Erfahrungen?
3. Jmd einen anderen (besseren) Vorschlag wie das zu lösen ist?

Anforderungen:
- Automatisches mitloggen aller geworfenen Exceptions (sprich Annotierte Exceptionschleudern müssen
diese nur noch behandeln.
- Tracing funktion auf dem Trace Level
- Das klassische oben genannte Logging muss in manchen Fällen trotzdem durchführbar sein... (INFO Level)
- Die performance natürlich so wenig wie möglich belasten!

Alle ratschläge sind herzlich willkommen...

Mfg Alex

 

[ralfgc]

Hallo,

diese Methode, wenn sie funktioniert, für Trace-Zwecke zu verwenden
ist im Prinzip an der Stelle irgendwo sinnvoll, aber ich versteh nicht ganz was du damit bezwecken
willst. Wenn eine Exception geworfen wird, dann wird sie sowieso bis
zu einer gewissen Schicht deiner Applikation weitergereicht und wahrscheinlich
auch geloggt. (catch Exception). Weiß ja nicht ob deine App in einem Application-Server
läuft, wenn ja dort auf jedenfall.

1: Also ein (catch Exception) an oberer Ebene des Funktionsaufrufs würde des Logging
dieser einschließen. Ein Logging "aller" Exceptions wäre dadurch gegeben.

2. 5% Leistungseinbuße für ein Tracing, wo der Sinn durchaus fragwürdig ist.
Das würde ich nicht eingehen. (Der Aufruf von Funktionen innerhalb kann durch
Tests abgedeckt werden.)

3. Das klassische Logging ist natürlich möglich.

4. Performance hängt eben von 2. ab. Das ist eig. der einzige Knackpunkt.

Gruß

 

[DamienX]

Hi danke für den Kommentar.

Also ich glaube du hast recht (ich bin heute aber nicht mehr im Stande
das zu ende zu denken)

Hier mein genauer Gedankengang...
Angenommen eine Verbindung bricht ab und löst eine checked Exception aus.
RemoteException zum Beispiel...

In der überliegenden Methode muss ich dies nun abfangen und behandeln.
In der ursprünglichen Methode allerdings (welche ja aufgerufen wurde und die exception auslöst) logge ich
die Exception samt Call Stack schon einmal weg.

Somit kann ich auf den codeteil in den Exception Blocks welcher für das letztendliche
loggen verantwortlich wäre verzichten.

Wie gesagt ich bin mir grad nicht ganz sich ob ich nicht genau in die falsche Richtung denke... *grmml*.
Call und Exception Stack laufen ja genau in die entgegengesetzte Richtung!? Oo

Ich werd morgen ein Beispiel dazu posten und die Sache durchtesten.
Heute is Schicht im Schacht.

Aber schon einmal danke für den Anstoß!!!

mfg Alex

 

[ralfgc]

Hallo,

die Exception kann wirklich in oberster Ebene gefangen werden, ohne einen
Verlust des Verursachsers zu erleiden.

bsp.

try {
  schritt1();
  schritt2(); // hier kommt vieleicht eine RemoteException, aber die wird geloggt
  ...
} catch (Exception ex) {
   // logge exception
}