P³ A new story begins

Un petit billet au sujet de la gestion des logs avec Java :

Si on se réfère au règles diverses (Checkstyle, PMD ...), voici la bonne façon de déclarer un logger en Java

// Pour Log4J avec commons-logging
private static final Log logger = LogFactory.getLog(MyClass.class);
 
// Pour logback avec slf4j
private static final Logger logger = LoggerFactory.getLogger(MyClass.class);

...Hein.. c'est quoi logback ???

Logback est le digne hériter de log4j, il a été conçu en même que les api slf4j par le créateur lui même de log4j: Ceki Gülcü

Il y a de nombreuses raisons d'utiliser logback, et elles sont toutes expliquées sur le site http://logback.qos.ch/reasonsToSwitch.html

Le seul défaut est que vous perdrez le niveau fatal, mais bon toutes les erreurs ne devraient-elles pas êtres évitées, et un niveau fatal devraient entrainer l'arrêt de l'application ??

Donc switchons tous ensemble :D

Revenons à nos moutons si on veut logger des évènements qui ont lieu dans une classe abstraite commune la bonne solution est de déclarer le logger protégé et de l'initialiser de manière statique.

protected transient final Logger logger = LoggerFactory.getLogger(this.getClass());

Toutefois cette déclaration n'est pas compatible avec une règle (qui à dit 'à la con') de PMD à savoir LoggerIsNotStaticFinal

Certains puristes veulent que la classe Abstraite et la classe fille ai chacune leur propre logger pour permettre de les filtrés différemment avec le fichier de configuration du gestionnaire de log. (cf ce billet )

Personnellement j'ai jamais voulu séparer les logs des méthodes abstraites hérités de celles déclarées dans la classe fille, surtout quand la pile d'appel est imbriqué et que plusieurs classes filles peuvent être appelés.

On pourrait ajouter l'information getClass() dans chaque log de la classe abstraite, mais c'est quand même relativement pénible

Donc comment faire ??

Une des solutions peut-être d'utiliser AOP => en bon français la Programmation par aspect (soit en bon anglais Aspect Oriented Programmation à opposer à la OOP)

Avec Spring AOP par exemple on peut ajouter des logs sur des points de coupe définissant des endroits où logger.

Voici la déclaration via le conteneur léger de spring (spring-beans):

<bean id="loggingAdvice" class="fr.webeo.rapidoo.aop.LoggingAdvice" />
 
<bean id="loggingAdvisor" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
	<property name="advice" ref="loggingAdvice" />
	<property name="pattern" value="fr.webeo.rapidoo.services" />
	<property name="order" value="50" />
</bean>

A vous de spécialiser votre point de coupe si vous voulez plus de précision, ici toutes les méthodes de toutes les classes du package fr.webeo.rapidoo.services seront traitées à la même enseigne !

Et l'advice qui va logger tout seul les classes filles

public class LoggingAdvice implements MethodBeforeAdvice, AfterReturningAdvice, ThrowsAdvice {
 
    /**
     * Default Constructor.
     */
    public LoggingAdvice() {
        // Nothing to do
    }
 
    /**
     * {@inheritDoc}
     */
    @Override
    public void before(final Method method, final Object[] args, final Object target) throws Throwable {
        final Logger logger = LoggerFactory.getLogger(target.getClass());
        if (logger.isInfoEnabled()) {
            logger.info("Calling : " + method.getName() + " " + target.getClass().getName());
        }
        if (logger.isDebugEnabled()) {
            final StringBuilder sb = new StringBuilder();
            sb.append("Parameters : ");
            if (method.getParameterTypes().length == args.length) {
                for (int i = 0; i < args.length; i++) {
                    sb.append("\r\nParam : ").append(method.getParameterTypes()[i]).append(" - ").append(args[i] == null ? "null" : args[i].toString());
                }
            }
            if (sb.length() > 1000) {
                logger.debug(sb.substring(0, 1000));
            } else {
                logger.debug(sb.toString());
            }
        }
    }
 
    /**
     * {@inheritDoc}
     */
    @Override
    public void afterReturning(final Object returnValue, final Method method, final Object[] args, final Object target) throws Throwable {
        final Logger logger = LoggerFactory.getLogger(target.getClass());
 
        if (logger.isInfoEnabled()) {
            logger.info("Returning : " + method.getName());
        }
        if (logger.isDebugEnabled() && returnValue != null) {
            if (returnValue instanceof List) {
                logger.debug("Return value is list of " + ((List<?>) returnValue).size() + " elements.");
            } else {
                logger.debug("Return Value = " + returnValue.toString());
            }
        }
    }
 
    /**
     * Call after an exception thrown.
     * 
     * @param method the method called
     * @param args the method arguments
     * @param target the object who call the method
     * @param exception the exception thrown
     */
    public void afterThrowing(final Method method, final Object[] args, final Object target, final Throwable exception) {
        final Logger logger = LoggerFactory.getLogger(target.getClass());
        if (logger.isErrorEnabled()) {
            logger.error("Throwing : " + method.getName() + " \r\n=> " + exception.getMessage(), exception);
        }
    }
}

Pour conclure il existe 3 possibilités pour logger des classes filles héritant d'une même classe abstraite :

• Un logger par classe

Avantages : Chaque ligne de la log renvoi vers la bonne classe physique

Défauts : les log contiendront des log par enfant et pour la classe mère, donc si quelque chose se passe mal dans la classe abstraite il faut espérer trouver à proximité une log indiquant quel est la classe fille concernée (ou bien la rajouter explicitement dans la ligne loggée)

• Déclaration du logger de la classe abstraite en protected non static

Avantages : Toutes les logs seront générés au nom de la classe fille

Défauts : les numéros de lignes des méthodes héritées concerneront la classe abstraite

• Déclaration des loggers via AOP :

Avantages : Déclaration très rapide, bonne personnalisation

Defauts : Seulement utile pour les log génériques, induit donc une bonne conception objet avec des méthodes courtes et atomiques
Et vous comment faîtes-vous ??