System.out.println. Quan vaig descobrir el Log4j, ja fa uns anys, va ser tot un encert. He conegut alternatives com java util logging (també conegut com JULI) o el Simple Logging Facade for Java (SL4J), però encara segueixo amb Log4j ja què és el que fan servir la majoria dels frameworks.La gràcia que té Log4j com a mecanisme de logging és que permet als desenvolupadors definir els tipus de missatges que volen que surtin (trace, debug, info, warning i error) i segons la configuració de l'aplicació es pintaran uns o uns altres. Si executes amb nivell de WARN sortiran els missatges d'error i de warning, però no sortiran els d'info, debug ni trace. És una jerarquia. A més a més, pots definir el nivell de log per cada classe, o per cada package o per descriptors que et puguis inventar, i pots fer que els missatges s'enregistrin en fitxers, que t'arribin per e-mail o moltes més virgueries.
Això sí, si treballes amb Maven cal anar amb compte per no tenir problemes amb el classloader. El jar del log4j no s'ha d'incloure a l'aplicació: a les dependencies pel log4j cal posar
<scope>provided</scope>.La definició de com vols que s'enregistrin els missatges es configura en un fitxer que s'anomena
log4j.properties o log4j.xml i la manera més fàcil d'ubicar-lo és al classpath. Una part molt delicada del projecte és configurar el fitxer de forma correcta i no equivocar-te de pujar el fitxer de desenvolupament a l'entorn d'explotació (o producció).Vaig aprendre que una manera de sobreviure a les diferents versions del log4j.properties era fer servir un paràmetre d'inicialització de la màquina virtual de java que li digués on buscar la configuració de log4j:
-Dlog4j.configuration=file:/c:/onsigui/log4j.properties. Això té avantatges i inconvenients, per què tenir un fitxer de configuració de logging independent de nous desplegaments, pot evitar-te complicacions en el desplegament, pot respectar-te les configuracions que hagi fet l'administrador de la instal·lació però també pots deixar de pujar configuracions de log4j que t'anirien bé tenir pel nou desplegament.Amb Spring Framework també li donen molta importància a la configuració de log4j i n'hi ha unes pràctiques definides de com ha d'anar i de com configurar el reload periòdic del fitxer de configuració, per poder-lo canviar en calent.
Però ara que faig servir JBoss com a servidor d'aplicacions he aprés una nova cosa força interessant: la definició del logging és una tasca de l'administrador de la instal·lació i no pas del desenvolupador. L'administrador sap com són els seus discos, on té més espai i quina retenció vol tenir dels missatges. Ha d'adquirir els coneixements per poder configurar el log4j (que no són tan complicats) i ha de saber els nivells de log que permet l'aplicació. El desenvolupador no ha de tenir un fitxer
log4j.properties preparat per cada instal·lació.La veritat és que aquest plantejament em sembla molt assenyat i és força alliberador.
Malauradament m'ha fet veure un error que he comés en el passat. Com que log4j és tan potent i tan fàcil de fer servir, de vegades l'he fet servir per coses que no li correspon. Dintre de les coses que vols enregistrar en disc puc pensar en: missatges de diagnòstic, missatges d'error complert, missatges d'auditoria d'accés, missatges d'auditoria de rendiment, ... Tots aquests tipus de missatge els anava enregistrant amb Log4j, i configurava el fitxer de properties de muntant un fitxer de log per cada tipus de missatge i donant-li característiques de rotació diferents.
Amb aquest nou plantejament de "la configuració de log4j és responsabilitat de l'administrador" es desmunta aquests usos que li donava. Els fitxers d'auditoria, per exemple, no haurien de poder ser desactivables per part de l'administrador, així que caldria enregistrar-los amb un mecanisme fora del log4j.
Crec que com a regla general podem dir:
- La configuració de log4j és responsabilitat de l'administrador de la instal·lació
- El logging que no s'ha de poder desactivar o modificar no s'ha de fer amb log4j.
No comments:
Post a Comment