Re: [Jug-Torino] Spring boot
Ciao, On Thu, Nov 8, 2018 at 11:53 PM Uberto Barbini uberto.g...@gmail.com [it-torino-java-jug] wrote: > in questo modo i log entrano a far parte del dominio, specifiche e tutto il > resto. Inoltre non c'e' piu' il concetto di debug/info/warn/trace ecc. o un > evento e' significativo e lo notifichi oppure no. Ma secondo me il problema è definire "significativo". Quello che è importante per qualcuno non lo è per qualcun altro. Io sono sempre stato un fan del tagged logging: niente livelli (debug/info/warn) ma solo tags. A quel punto come dici tu il logging diventa una feature e cosa devi loggare dal punto di vista del business lo chiedi al cliente, mentre lo sviluppatore fa il logging degli internals dell'implementazione. Da Java 9 si è arrivati a questo per il logging interno della JVM, ma niente da fare ancora per il logging applicativo e i vari SLF4J, Log4J2 e LogBack che sono ancorati al modello di 20-30 anni fa. > Kirk Pepperdine mi ha fatto notare una volta come uno dovrebbe loggare il > meno possibile quando va tutto bene e il piu' possible quando succede qualche > cosa di sbagliato. Anche qui definire "sbagliato" è difficile. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Re: [Jug-Torino] Spring boot
> > > >> Il punto e' che invece di avere loggerXY esiste un monitor che chi vuole >> loggare qualcosa deve farsi "prestare" (no DI automatico) e ognuno >> definisce gli eventi con i loro campi. >> E' un modo incredibilmente produttivo, sia per chi scrive codice che per >> chi deve cercare i bugs che evita tonnellate di logs inutili. >> > > Questo puoi approfondirlo meglio? Mi interessa l'approccio ma non ho > capito le differenze da un classico log file, al di la del formato dati e > dello storage. > la differenza maggiore per il dev e' che invece di mettere un logger statico singleton in ogni classe dove vuole loggare qualcosa, deve: 1) passare un'istanza del monitor fino al metodo che vuole loggare 2) definire un evento di dominio (enum/sealed class) per l'evento da loggare. in questo modo i log entrano a far parte del dominio, specifiche e tutto il resto. Inoltre non c'e' piu' il concetto di debug/info/warn/trace ecc. o un evento e' significativo e lo notifichi oppure no. Kirk Pepperdine mi ha fatto notare una volta come uno dovrebbe loggare il meno possibile quando va tutto bene e il piu' possible quando succede qualche cosa di sbagliato. Mentre invece i log classici sono superverbosi quando non succede nulla e poi l'evento critico ha solo una riga (se va bene) senza tutte le info che servono. Con questo sistema ci stiamo avvicinando molto all'ideale di Kirk... Uberto
