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

----- Original Message ----- > From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > To: "Moti Asayag" <masayag(a)redhat.com&gt; > Cc: devel(a)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(a)redhat.com&gt; >> To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; >> Cc: devel(a)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(a)redhat.com&gt; >>> To: devel(a)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(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel