[ovirt-devel] Question/thoughts about our engine logging framework
Alon Bar-Lev
alonbl at redhat.com
Sun Jun 15 15:07:28 UTC 2014
----- Original Message -----
> From: "Martin Perina" <mperina at redhat.com>
> To: "Greg Sheremeta" <gshereme at redhat.com>
> Cc: devel at ovirt.org
> Sent: Sunday, June 15, 2014 5:34:51 PM
> Subject: Re: [ovirt-devel] Question/thoughts about our engine logging framework
>
>
>
> ----- Original Message -----
> > From: "Greg Sheremeta" <gshereme at redhat.com>
> > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > Cc: devel at ovirt.org
> > Sent: Sunday, June 15, 2014 4:25:54 PM
> > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging
> > framework
> >
> >
> >
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > Cc: devel at ovirt.org
> > > Sent: Sunday, June 15, 2014 10:02:15 AM
> > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging
> > > framework
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > To: "Martin Perina" <mperina at redhat.com>
> > > > Cc: devel at ovirt.org
> > > > Sent: Friday, June 13, 2014 12:57:49 PM
> > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging
> > > > framework
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Martin Perina" <mperina at redhat.com>
> > > > > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > > > Cc: devel at ovirt.org
> > > > > Sent: Friday, June 13, 2014 10:43:59 AM
> > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging
> > > > > framework
> > > > >
> > > > > Hi Yair,
> > > > >
> > > > > I had in my mind to clean up logging framework mess for quite some
> > > > > time
> > > > > :-)
> > > > > Currently this is the usage of logging frameworks in engine classes:
> > > > >
> > > > > java.util.logging.Logger 6.8%
> > > > > org.apache.commons.logging.Log 7.8%
> > > > > org.apache.log4j.Logger 13.6%
> > > > > org.ovirt.engine.core.utils.log.Log 68.8%
> > > > > org.slf4j.Logger 2.9%
> > > > >
> > > > > I think we should definitely use only 1 logging framework for the
> > > > > whole
> > > > > engine!
> > > > >
> > > > > So +1 to slf4j from me.
> > > >
> > > > +1 from me as well.
> > >
> > > +1
> > >
> > +1 to slf4j. I started using that exclusively in Java projects 4 years ago
> > :)
> >
> > Just be careful if we're introducing it as a new dependency. (It's provided
> > by Fedora, but there might be conflicts if JBoss/Wildfly uses it. We should
> > use that same version, if it does.)
>
> We already have a dependency to slf4j 1.7.5 in the root pom.xml. And AFAIK
> 1.7.2 is a part of EAP 6.
The jboss we are using provides slf4j-1.6.1, while it seems to be patched to support varargs[1] as 1.7.x.
As standalone at fedora there is slf4j which is compatible and at rhel there is slf4j-eap6 both are 1.7.x.
However for centos we use jpackage which provides only 1.6.1[2].
So for standalone packages we may experience issues if were build using varargs.
[1] logger.debug("format", obj1, obj2, obj3, ...)
[2] http://jpackage.org/browser/rpm.php?jppversion=6.0&id=12435
>
> >
> > > >
> > > > Note that GWT UI code uses java.util.logging exclusively to do all
> > > > logging.
> > > > (GWT emulates java.util.logging API and provides log handlers for use
> > > > on
> > > > client side such as console.log() or stdout/DevMode-during-debug
> > > > handlers.)
> > > >
> > > > >
> > > > > And once we agree to 1 logging framework, I can start preparing
> > > > > patches
> > > > > to
> > > > > use it.
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > > > > To: devel at ovirt.org
> > > > > > Sent: Friday, June 13, 2014 8:15:55 AM
> > > > > > Subject: [ovirt-devel] Question/thoughts about our engine logging
> > > > > > framework
> > > > > >
> > > > > > Hi all,
> > > > > > During my recent work on AAA, I was suggested by Juan Hernandez to
> > > > > > use
> > > > > > slf4j
> > > > > > logging framework which serves as a facade for other logging
> > > > > > frameworks
> > > > > > (including java utils logging which is now used by jboss), log4j
> > > > > > and
> > > > > > others.
> > > > > > I have accepted Juan's offer, and then when looking at our
> > > > > > LogFactory
> > > > > > class
> > > > > > I
> > > > > > have noticed we use commons logging.
> > > > > >
> > > > > > Several thoughts/questions -
> > > > > > A. Why continue use our own wrapper as slf4j is already a facade.
> > > > > > b. I think we should move cross java code to slf4j. What do you
> > > > > > think
> > > > > > on
> > > > > > this
> > > > > > point?
> > > > > >
> > > > > > Some reading material -
> > > > > >
> > > > > > http://javarevisited.blogspot.com.au/2013/08/why-use-sl4j-over-log4j-for-logging-in.html
> > > > > > http://stackoverflow.com/questions/3222895/what-is-the-issue-with-the-runtime-discovery-algorithm-of-apache-commons-logging
> > > > > >
> > > > > >
> > > > > >
> > > > > > Yair
> > > > > > _______________________________________________
> > > > > > 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
> > > > >
> > > > _______________________________________________
> > > > 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
> > >
> > _______________________________________________
> > 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
>
More information about the Devel
mailing list