On 10/20/2014 01:40 PM, Martin Perina wrote:
----- Original Message -----
From: "Alon Bar-Lev" <[email protected]>
To: "Moti Asayag" <[email protected]>
Cc: [email protected]
Sent: Monday, October 20, 2014 12:22:25 PM
Subject: Re: [ovirt-devel] [ATN] [ovirt-engine] engine master logging
----- Original Message -----
From: "Moti Asayag" <[email protected]>
To: "Alon Bar-Lev" <[email protected]>
Cc: [email protected]
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" <[email protected]>
To: [email protected]
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
+1 nice work
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
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel
