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:
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...
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
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:
Code:
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...
Code:
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