[ovirt-devel] [ATN] [ovirt-engine] engine master logging

[Martin Perina]

----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: devel at ovirt.org
> Sent: Monday, October 20, 2014 12:22:25 PM
> Subject: Re: [ovirt-devel] [ATN] [ovirt-engine] engine master logging
> 
> 
> 
> ----- Original Message -----
> > From: "Moti Asayag" <masayag at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: devel at ovirt.org
> > Sent: Monday, October 20, 2014 1:14:51 PM
> > Subject: Re: [ovirt-devel] [ATN] [ovirt-engine] engine master logging
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: devel at ovirt.org
> > > Sent: Sunday, October 19, 2014 9:02:52 PM
> > > Subject: [ovirt-devel] [ATN] [ovirt-engine] engine master logging
> > > 
> > > Hello All,
> > > 
> > > Thanks to Martin Perina efforts[1] the ovirt-engine logging was cleaned
> > > up
> > > significantly throughout the engine.
> > > 
> > > 1. Logging Facade is slf4j.
> > > 2. Logging backend is jboss logging at jboss and java.util.logging at
> > > standalone.
> > > 3. No more commons-logging, log4j, combinations nor proprietary loggers.
> > > 
> > 
> > Nice work. I was about to write "I guess the next step will be clearing the
> > ThreadLocalParametersContainer" - but noticed it was already removed.
> > 
> > > The org.ovirt.engine.core.utils.log.LogFactory and
> > > org.ovirt.engine.core.utils.log.Log are depreciated now, the correlation
> > > id
> > > is managed using logging MDC, so no need to use wrapper, and correlation
> > > has
> > > much wider effect, as also 3rd parties log records are attached with
> > > correlation id.
> > 
> > Would you consider extending the declaration of @Depracated for those
> > classes
> > with more information for the sake of those who might miss this email and
> > should
> > know what is the proper replacement for the deprecated logging method ?
> 
> as I wrote we will remove this classes soon using mass changes.
> in few days there will be no reference for these.

Yes, I'm currently preparing patches for this, so hopefully within week or two
those classes will be removed from project

> 
> > > 
> > > We will start to push changes to remove the usage of these classes in
> > > favor
> > > of plain slf4j loggers.
> > > 
> > > Quick lineup...
> > > 
> > > 1. Usage:
> > > import org.slf4j.Logger;
> > > import org.slf4j.LoggerFactory;
> > > class x {
> > >     private static final Logger log = LoggerFactory.getLogger(x.class);
> > > }
> > > 
> > > 2. slf4j logger javadoc is here[2].
> > > 
> > > 3. Crash course:
> > > 
> > > // simple string
> > > log.info("string");
> > > 
> > > // string with exception and stack trace
> > > log.info("string", exception);
> > > 
> > > // string with vars, logger will call argN.toString() for each {}.
> > > log.info("string {} {} {}", arg1, arg2, arg3);
> > > 
> > > 4. *NOTICE* Major difference than what we had:
> > > 
> > > Exception arguments are not "magically" detected.
> > > 
> > > // previous (utils Log): "exception" magically detected.
> > > log.infoFormat("string {0}", arg1, exception);
> > > 
> > > // new (slf4j):
> > > log.info("string {}", arg1);
> > > log.info("Exception", exception);
> > > 
> > > // better new (slf4j):
> > > log.info("string {}", arg1);
> > > log.debug("Exception", exception);
> > > 
> > > Please do not hesitate to raise any related issue you may find.
> > > 
> > > Regards,
> > > Alon Bar-Lev.
> > > 
> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1109871
> > > [2] http://www.slf4j.org/api/org/slf4j/Logger.html
> > > _______________________________________________
> > > Devel mailing list
> > > Devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
> > > 
> > 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>