Newsgroup: it.comp.java
Titolo: logger statico e testing

Non ho mai usato log4j e lo sto per fare ora.
Vedo che generalmente è consigliato fare:
static Logger log4j = Logger.getLogger("org.example.foo.bar");
in una classe, in modo da avere il logger disponibile per i vari metodi.
Ma, mettiamo poi che io voglia testare quella classe, o ancora di più,
riutilizzare da qualche altra parte, sbaglio o è un male usare così il
logger?
Complico troppo le cose, pensando che si dovrebbe usare l'inversion of
control, e passare il logger alla classe, da quella che la chiama?
-- 
Herbie

 
Puoi anche farlo, ma a cosa serve? Cosa controlli? E il vantaggio quale 
sarebbe? Che risparmi una riga di codice?


Ci sono framework che ti consentono l'injection del logger ad esempio 
Seam, Spring, CDI:
class  MyClass {
   @Logger Log myLog;
   ...
}
e questo principalmente per evitare di scrivere righe del tipo
static Logger log = Logger.getLogger(MyClass.class);
che sono effettivamente verbose. Ma in generale in assenza di questi 
meccanismi di injection, puoi usare benissimo con il metodo classico.
In particolare lascerei stare l'impostazione manuale nel chiamante, in 
quanto proprio non ne vale la pena.
-- 
Il CGI secondo Radicale: una specie di linguaggio per fare query su 
siti,internet.

 sarebbe? Che risparmi una riga di codice?
mah, non tanto quello, perché ci sarebbe un parametro in più da passare
al costruttore o un setter da chiamare. Il problema che mi ponevo era la
fase di testing, o, volendo generalizzare, di riuso delle classi
(mettiamo che le distribuiamo senza sorgenti, per esempio)
-- 
Herbie

 quanto proprio non ne vale la pena.
Va bene, ma per il test della classe? Mi rimane di impostare il log a
off prima di chiamare i metodi di test? 
Avevo letto di Log4unit, ma sinceramente non ho capito bene cosa faccio
e se potrebbe essermi utile in un caso come questo, in cui un classe
logga
-- 
Herbie


In fase di test potresti semplicemente utilizzare un diverso file di
configurazione di log4j in modo da non loggare nulla.
In alternativa, potresti utilizzare una libreria di logging come
slf4j, utilizzando poi il binding per log4j (slf4j-log4j), con
configurazione opportuna di quest'ultimo, in "produzione", mentre nei
test automatici potresti utilizzare il binding che slf4j-nop, che non
logga nulla.
In questo modo tra l'altro ti metti nelle condizioni di far convivere
facilmente la tua applicazione con librerie che utilizzano sistemi di
logging diversi da quello scelto da te (c'è chi usa JDK logger, chi
usa JavaCommonsLogging come wrapper, ...).
Se la cosa ti può interessare, prova a dare un'occhiata qui:
http://www.slf4j.org/
 .
Buona giornata!

 off prima di chiamare i metodi di test?
Non ho capito perché il log in fase di test ti da così fastidio.
Comunque puoi sempre cambiare i livelli di logging nel file di
configurazione (il tuo processo di build dovrà copiare nel classpath
il log4j.properties o xml corretto a seconda che tu stia testando o
compilando per lo sviluppo o produzione) .

 (mettiamo che le distribuiamo senza sorgenti, per esempio)
Il logger sul costruttore è roba da peracottari. Il log non dovrebbe
entrare nella semantica della classe, e' un aspetto ortogonale che
meno si vede meglio è. Passi il setter, ma il parametro nel
costruttore è una pratica immonda.

 parametro nel costruttore è una pratica immonda.
Va bene, mi asterrò da pratiche immonde, visto che poi mi piace codice
elegante :)
-- 
Herbie

 compilando per lo sviluppo o produzione) .
Ma se non sbaglio si può impostare log4j da codice, "overridando"
l'eventuale properties presente?
-- 
Herbie

 configurazione di log4j in modo da non loggare nulla.
tutto sommato, questa è la soluzione più semplice
-- 
Herbie

 potrebbe voler consultare il log...
Appunto e allora continuo a non capire perché non puoi semplicemente 
continuare a loggare come loggavi in sviluppo. Boh.

 
Beh, se le distribuisci senza sorgenti non usare il log4j, tanto per 
rispettare la licenza.

 rispettare la licenza.
Ue, sei pazzo? ;) Non potremmo utilizzare log4j in applicazioni
commerciali.
Ad esempio per la LGPL (non so quale sia la licenza di log4j)
l'obbligo di redistribuire i sorgenti non si applica nel caso venga
usato come libreria di terze parti.
Chiaro, se estendi log4j creando il tuo mylog4j allora penso tu debba
redistribuire i sorgenti di mylog4j.

 redistribuire i sorgenti di mylog4j.
Log4J utilizza la licenza apache, 
http://it.wikipedia.org/wiki/Apache_License
, che essendo più 
restrittiva della copyleft non obbliga alla redistribuzione dei 
sorgenti.
-- 
Morde