You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mahout.apache.org by "Sean Owen (JIRA)" <ji...@apache.org> on 2008/05/10 21:39:55 UTC
[jira] Created: (MAHOUT-52) Standardize on java.util.logging,
Commons Logging, log4j?
Standardize on java.util.logging, Commons Logging, log4j?
---------------------------------------------------------
Key: MAHOUT-52
URL: https://issues.apache.org/jira/browse/MAHOUT-52
Project: Mahout
Issue Type: Improvement
Reporter: Sean Owen
Priority: Minor
I see the log4j and Commons Logging .jars in the lib/ directory. log4j isn't used; Commons Logging is used in one class (Parametered). My code just used java.util.logging directly.
I figure we should standardize on one approach to logging. I personally think they're all just about the same; the only real best practice is using one system.
I have always just used java.util.logging since it is built into Java 1.4+. Commons Logging offers an extra layer of abstraction and lets you switch between java.util.logging and log4j underneath. That's cool, but I've not found it compelling enough to want to add another layer and another .jar file.
But, I guess log4j is present because hadoop uses it directly? The .jar seems to have a dependency on it.
In that case maybe we are better off using Commons Logging to let us integrate with log4j logging that Hadoop uses, and leave open the possibility of other callers using java.util.logging underneath.
If that's cool I can switch my code to use Commons Logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (MAHOUT-52) Standardize on java.util.logging, Commons Logging, log4j?
Posted by Grant Ingersoll <gs...@apache.org>.
there's been a pretty good debate over on Solr Dev about this. My
preference would either be SLF4J or Log4j. Commons logging has a lot
of known issues with the way it handles classloading, and even the
creators only recommend it's use in certain situations. I would
recommend we go to SLF4J, but Log4j is good too. Do we know what
Hadoop uses? That would be the other preference.
On May 10, 2008, at 3:39 PM, Sean Owen (JIRA) wrote:
> Standardize on java.util.logging, Commons Logging, log4j?
> ---------------------------------------------------------
>
> Key: MAHOUT-52
> URL: https://issues.apache.org/jira/browse/MAHOUT-52
> Project: Mahout
> Issue Type: Improvement
> Reporter: Sean Owen
> Priority: Minor
>
>
> I see the log4j and Commons Logging .jars in the lib/ directory.
> log4j isn't used; Commons Logging is used in one class
> (Parametered). My code just used java.util.logging directly.
>
> I figure we should standardize on one approach to logging. I
> personally think they're all just about the same; the only real best
> practice is using one system.
>
> I have always just used java.util.logging since it is built into
> Java 1.4+. Commons Logging offers an extra layer of abstraction and
> lets you switch between java.util.logging and log4j underneath.
> That's cool, but I've not found it compelling enough to want to add
> another layer and another .jar file.
>
> But, I guess log4j is present because hadoop uses it directly?
> The .jar seems to have a dependency on it.
>
> In that case maybe we are better off using Commons Logging to let us
> integrate with log4j logging that Hadoop uses, and leave open the
> possibility of other callers using java.util.logging underneath.
>
> If that's cool I can switch my code to use Commons Logging.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
Re: [jira] Commented: (MAHOUT-52) Standardize on java.util.logging, Commons Logging, log4j?
Posted by Ted Dunning <te...@gmail.com>.
+1
On Mon, May 12, 2008 at 7:50 PM, Sean Owen (JIRA) <ji...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/MAHOUT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596254#action_12596254]
>
> Sean Owen commented on MAHOUT-52:
> ---------------------------------
>
> Actually from looking more al SLF4J I like it more. The static binding
> thing is nice, and so this can automatically use JCL to integrate with
> Hadoop if needed (yeah, a facade of a facade :( ).
>
> I vote +1. I think I hear a few more votes in favor. Are we agreed? I can
> change my code then convert other System.out.println and so on.
>
> > Standardize on java.util.logging, Commons Logging, log4j?
> > ---------------------------------------------------------
> >
> > Key: MAHOUT-52
> > URL: https://issues.apache.org/jira/browse/MAHOUT-52
> > Project: Mahout
> > Issue Type: Improvement
> > Reporter: Sean Owen
> > Priority: Minor
> >
> > I see the log4j and Commons Logging .jars in the lib/ directory. log4j
> isn't used; Commons Logging is used in one class (Parametered). My code just
> used java.util.logging directly.
> > I figure we should standardize on one approach to logging. I personally
> think they're all just about the same; the only real best practice is using
> one system.
> > I have always just used java.util.logging since it is built into Java
> 1.4+. Commons Logging offers an extra layer of abstraction and lets you
> switch between java.util.logging and log4j underneath. That's cool, but I've
> not found it compelling enough to want to add another layer and another .jar
> file.
> > But, I guess log4j is present because hadoop uses it directly? The .jar
> seems to have a dependency on it.
> > In that case maybe we are better off using Commons Logging to let us
> integrate with log4j logging that Hadoop uses, and leave open the
> possibility of other callers using java.util.logging underneath.
> > If that's cool I can switch my code to use Commons Logging.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
--
ted
Re: [jira] Commented: (MAHOUT-52) Standardize on java.util.logging, Commons Logging, log4j?
Posted by Sean Owen <sr...@gmail.com>.
I mean I'm sure up for it, if now three people are saying this is a
good option. I'm halfway through porting my code to JCL, so, let's
take a decision. :)
Shall we vote just to move forward here? I split my vote 0.5 for JCL
and 0.5 for SLF4J, given the discussion to date.
On Mon, May 12, 2008 at 6:05 PM, Ted Dunning <te...@gmail.com> wrote:
> SLF4J has the significant advantage that is can adapt easily to any mainline
> logging convention when Mahout is included as part of some other project.
> Whether the including project's convention is java.util, commons, log4j or
> slf4j, the use of slf by us will allow our code to conform to the outer
> level standard by the simple selection of which slf jar file the outer
> project includes. This would make it much easier to adopt our software.
>
> I don't think that any other choice will allow that.
>
> On Mon, May 12, 2008 at 2:55 PM, Sean Owen (JIRA) <ji...@apache.org> wrote:
>
> >
> > [
>
>
> > https://issues.apache.org/jira/browse/MAHOUT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596212#action_12596212]
> >
> > Sean Owen commented on MAHOUT-52:
> > ---------------------------------
> >
> > I could not agree more that logging is important.
> >
> > I think the blog post echoes my sentiment that a *facade* logging system
> > probably adds little value in many situations. I'm not sure he was
> > suggesting JCL itself is a bad choice. He also says what I suspected, that
> > classloader-related gripes about JCL are not specific to JCL. If it's what
> > I'm thinking of, yeah, this comes up for log4j or any other such system
> > where a parent classloader's copy of the classes are used, but, it tries to
> > load some class known only to the child classloader by reflection -- which
> > would work fine when on the child classloader exists.
> >
> > If all that's right, then that's an equal argument against both JCL and
> > SLF4J. I'd reopen the debate about whether we should use log4j or
> > java.util.logging directly then, but I feel like there is some consensus
> > here around just using what Hadoop uses since this will be tying in tightly
> > with Hadoop.
> >
> > And then that is an arugment for JCL over SLF4J.
> >
> > SLF4J *does* have a nice solution for the "if (debug enabled) {...}"
> > idiom, which is to use a lightweight message format system. I suppose I'd
> > say it's no less necessary that the developer be cognizant of the
> > performance issue here; the solution is just different.
> >
> > I suppose I am still not sold on using SLF4J but that's now two people
> > that have voiced some support for it, so I am intrigued. At the moment I
> > personally still find the "use what Hadoop uses" argument most compelling.
> > If we introduce SLF4J... consider that then our combined package will use,
> > count 'em, *four* different logging systems.
> >
> > (I really hope Hadoop standardizes here. I wonder if, eh, we can send over
> > some patches?)
> >
> > > Standardize on java.util.logging, Commons Logging, log4j?
> > > ---------------------------------------------------------
> > >
> > > Key: MAHOUT-52
> > > URL: https://issues.apache.org/jira/browse/MAHOUT-52
> > > Project: Mahout
> > > Issue Type: Improvement
> > > Reporter: Sean Owen
> > > Priority: Minor
> > >
> > > I see the log4j and Commons Logging .jars in the lib/ directory. log4j
> > isn't used; Commons Logging is used in one class (Parametered). My code just
> > used java.util.logging directly.
> > > I figure we should standardize on one approach to logging. I personally
> > think they're all just about the same; the only real best practice is using
> > one system.
> > > I have always just used java.util.logging since it is built into Java
> > 1.4+. Commons Logging offers an extra layer of abstraction and lets you
> > switch between java.util.logging and log4j underneath. That's cool, but I've
> > not found it compelling enough to want to add another layer and another .jar
> > file.
> > > But, I guess log4j is present because hadoop uses it directly? The .jar
> > seems to have a dependency on it.
> > > In that case maybe we are better off using Commons Logging to let us
> > integrate with log4j logging that Hadoop uses, and leave open the
> > possibility of other callers using java.util.logging underneath.
> > > If that's cool I can switch my code to use Commons Logging.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>
>
> --
> ted
>
Re: [jira] Commented: (MAHOUT-52) Standardize on java.util.logging, Commons Logging, log4j?
Posted by Ted Dunning <te...@gmail.com>.
SLF4J has the significant advantage that is can adapt easily to any mainline
logging convention when Mahout is included as part of some other project.
Whether the including project's convention is java.util, commons, log4j or
slf4j, the use of slf by us will allow our code to conform to the outer
level standard by the simple selection of which slf jar file the outer
project includes. This would make it much easier to adopt our software.
I don't think that any other choice will allow that.
On Mon, May 12, 2008 at 2:55 PM, Sean Owen (JIRA) <ji...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/MAHOUT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596212#action_12596212]
>
> Sean Owen commented on MAHOUT-52:
> ---------------------------------
>
> I could not agree more that logging is important.
>
> I think the blog post echoes my sentiment that a *facade* logging system
> probably adds little value in many situations. I'm not sure he was
> suggesting JCL itself is a bad choice. He also says what I suspected, that
> classloader-related gripes about JCL are not specific to JCL. If it's what
> I'm thinking of, yeah, this comes up for log4j or any other such system
> where a parent classloader's copy of the classes are used, but, it tries to
> load some class known only to the child classloader by reflection -- which
> would work fine when on the child classloader exists.
>
> If all that's right, then that's an equal argument against both JCL and
> SLF4J. I'd reopen the debate about whether we should use log4j or
> java.util.logging directly then, but I feel like there is some consensus
> here around just using what Hadoop uses since this will be tying in tightly
> with Hadoop.
>
> And then that is an arugment for JCL over SLF4J.
>
> SLF4J *does* have a nice solution for the "if (debug enabled) {...}"
> idiom, which is to use a lightweight message format system. I suppose I'd
> say it's no less necessary that the developer be cognizant of the
> performance issue here; the solution is just different.
>
> I suppose I am still not sold on using SLF4J but that's now two people
> that have voiced some support for it, so I am intrigued. At the moment I
> personally still find the "use what Hadoop uses" argument most compelling.
> If we introduce SLF4J... consider that then our combined package will use,
> count 'em, *four* different logging systems.
>
> (I really hope Hadoop standardizes here. I wonder if, eh, we can send over
> some patches?)
>
> > Standardize on java.util.logging, Commons Logging, log4j?
> > ---------------------------------------------------------
> >
> > Key: MAHOUT-52
> > URL: https://issues.apache.org/jira/browse/MAHOUT-52
> > Project: Mahout
> > Issue Type: Improvement
> > Reporter: Sean Owen
> > Priority: Minor
> >
> > I see the log4j and Commons Logging .jars in the lib/ directory. log4j
> isn't used; Commons Logging is used in one class (Parametered). My code just
> used java.util.logging directly.
> > I figure we should standardize on one approach to logging. I personally
> think they're all just about the same; the only real best practice is using
> one system.
> > I have always just used java.util.logging since it is built into Java
> 1.4+. Commons Logging offers an extra layer of abstraction and lets you
> switch between java.util.logging and log4j underneath. That's cool, but I've
> not found it compelling enough to want to add another layer and another .jar
> file.
> > But, I guess log4j is present because hadoop uses it directly? The .jar
> seems to have a dependency on it.
> > In that case maybe we are better off using Commons Logging to let us
> integrate with log4j logging that Hadoop uses, and leave open the
> possibility of other callers using java.util.logging underneath.
> > If that's cool I can switch my code to use Commons Logging.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
--
ted
[jira] Updated: (MAHOUT-52) Standardize on java.util.logging,
Commons Logging, log4j?
Posted by "Karl Wettin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAHOUT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karl Wettin updated MAHOUT-52:
------------------------------
Fix Version/s: 0.1
> Standardize on java.util.logging, Commons Logging, log4j?
> ---------------------------------------------------------
>
> Key: MAHOUT-52
> URL: https://issues.apache.org/jira/browse/MAHOUT-52
> Project: Mahout
> Issue Type: Improvement
> Reporter: Sean Owen
> Priority: Minor
> Fix For: 0.1
>
>
> I see the log4j and Commons Logging .jars in the lib/ directory. log4j isn't used; Commons Logging is used in one class (Parametered). My code just used java.util.logging directly.
> I figure we should standardize on one approach to logging. I personally think they're all just about the same; the only real best practice is using one system.
> I have always just used java.util.logging since it is built into Java 1.4+. Commons Logging offers an extra layer of abstraction and lets you switch between java.util.logging and log4j underneath. That's cool, but I've not found it compelling enough to want to add another layer and another .jar file.
> But, I guess log4j is present because hadoop uses it directly? The .jar seems to have a dependency on it.
> In that case maybe we are better off using Commons Logging to let us integrate with log4j logging that Hadoop uses, and leave open the possibility of other callers using java.util.logging underneath.
> If that's cool I can switch my code to use Commons Logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAHOUT-52) Standardize on java.util.logging,
Commons Logging, log4j?
Posted by "Pi Song (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAHOUT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596071#action_12596071 ]
Pi Song commented on MAHOUT-52:
-------------------------------
Hello guys. I'm a visitor.
Myself find java.util.logging API ugly but log4j pretty. This is too subjective to be a factor for decision.
> Standardize on java.util.logging, Commons Logging, log4j?
> ---------------------------------------------------------
>
> Key: MAHOUT-52
> URL: https://issues.apache.org/jira/browse/MAHOUT-52
> Project: Mahout
> Issue Type: Improvement
> Reporter: Sean Owen
> Priority: Minor
>
> I see the log4j and Commons Logging .jars in the lib/ directory. log4j isn't used; Commons Logging is used in one class (Parametered). My code just used java.util.logging directly.
> I figure we should standardize on one approach to logging. I personally think they're all just about the same; the only real best practice is using one system.
> I have always just used java.util.logging since it is built into Java 1.4+. Commons Logging offers an extra layer of abstraction and lets you switch between java.util.logging and log4j underneath. That's cool, but I've not found it compelling enough to want to add another layer and another .jar file.
> But, I guess log4j is present because hadoop uses it directly? The .jar seems to have a dependency on it.
> In that case maybe we are better off using Commons Logging to let us integrate with log4j logging that Hadoop uses, and leave open the possibility of other callers using java.util.logging underneath.
> If that's cool I can switch my code to use Commons Logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAHOUT-52) Standardize on java.util.logging,
Commons Logging, log4j?
Posted by "Sean Owen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAHOUT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596212#action_12596212 ]
Sean Owen commented on MAHOUT-52:
---------------------------------
I could not agree more that logging is important.
I think the blog post echoes my sentiment that a *facade* logging system probably adds little value in many situations. I'm not sure he was suggesting JCL itself is a bad choice. He also says what I suspected, that classloader-related gripes about JCL are not specific to JCL. If it's what I'm thinking of, yeah, this comes up for log4j or any other such system where a parent classloader's copy of the classes are used, but, it tries to load some class known only to the child classloader by reflection -- which would work fine when on the child classloader exists.
If all that's right, then that's an equal argument against both JCL and SLF4J. I'd reopen the debate about whether we should use log4j or java.util.logging directly then, but I feel like there is some consensus here around just using what Hadoop uses since this will be tying in tightly with Hadoop.
And then that is an arugment for JCL over SLF4J.
SLF4J *does* have a nice solution for the "if (debug enabled) {...}" idiom, which is to use a lightweight message format system. I suppose I'd say it's no less necessary that the developer be cognizant of the performance issue here; the solution is just different.
I suppose I am still not sold on using SLF4J but that's now two people that have voiced some support for it, so I am intrigued. At the moment I personally still find the "use what Hadoop uses" argument most compelling. If we introduce SLF4J... consider that then our combined package will use, count 'em, *four* different logging systems.
(I really hope Hadoop standardizes here. I wonder if, eh, we can send over some patches?)
> Standardize on java.util.logging, Commons Logging, log4j?
> ---------------------------------------------------------
>
> Key: MAHOUT-52
> URL: https://issues.apache.org/jira/browse/MAHOUT-52
> Project: Mahout
> Issue Type: Improvement
> Reporter: Sean Owen
> Priority: Minor
>
> I see the log4j and Commons Logging .jars in the lib/ directory. log4j isn't used; Commons Logging is used in one class (Parametered). My code just used java.util.logging directly.
> I figure we should standardize on one approach to logging. I personally think they're all just about the same; the only real best practice is using one system.
> I have always just used java.util.logging since it is built into Java 1.4+. Commons Logging offers an extra layer of abstraction and lets you switch between java.util.logging and log4j underneath. That's cool, but I've not found it compelling enough to want to add another layer and another .jar file.
> But, I guess log4j is present because hadoop uses it directly? The .jar seems to have a dependency on it.
> In that case maybe we are better off using Commons Logging to let us integrate with log4j logging that Hadoop uses, and leave open the possibility of other callers using java.util.logging underneath.
> If that's cool I can switch my code to use Commons Logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MAHOUT-52) Standardize on java.util.logging,
Commons Logging, log4j?
Posted by "Sean Owen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAHOUT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sean Owen resolved MAHOUT-52.
-----------------------------
Resolution: Fixed
> Standardize on java.util.logging, Commons Logging, log4j?
> ---------------------------------------------------------
>
> Key: MAHOUT-52
> URL: https://issues.apache.org/jira/browse/MAHOUT-52
> Project: Mahout
> Issue Type: Improvement
> Reporter: Sean Owen
> Priority: Minor
>
> I see the log4j and Commons Logging .jars in the lib/ directory. log4j isn't used; Commons Logging is used in one class (Parametered). My code just used java.util.logging directly.
> I figure we should standardize on one approach to logging. I personally think they're all just about the same; the only real best practice is using one system.
> I have always just used java.util.logging since it is built into Java 1.4+. Commons Logging offers an extra layer of abstraction and lets you switch between java.util.logging and log4j underneath. That's cool, but I've not found it compelling enough to want to add another layer and another .jar file.
> But, I guess log4j is present because hadoop uses it directly? The .jar seems to have a dependency on it.
> In that case maybe we are better off using Commons Logging to let us integrate with log4j logging that Hadoop uses, and leave open the possibility of other callers using java.util.logging underneath.
> If that's cool I can switch my code to use Commons Logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAHOUT-52) Standardize on java.util.logging,
Commons Logging, log4j?
Posted by "Sean Owen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAHOUT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596254#action_12596254 ]
Sean Owen commented on MAHOUT-52:
---------------------------------
Actually from looking more al SLF4J I like it more. The static binding thing is nice, and so this can automatically use JCL to integrate with Hadoop if needed (yeah, a facade of a facade :( ).
I vote +1. I think I hear a few more votes in favor. Are we agreed? I can change my code then convert other System.out.println and so on.
> Standardize on java.util.logging, Commons Logging, log4j?
> ---------------------------------------------------------
>
> Key: MAHOUT-52
> URL: https://issues.apache.org/jira/browse/MAHOUT-52
> Project: Mahout
> Issue Type: Improvement
> Reporter: Sean Owen
> Priority: Minor
>
> I see the log4j and Commons Logging .jars in the lib/ directory. log4j isn't used; Commons Logging is used in one class (Parametered). My code just used java.util.logging directly.
> I figure we should standardize on one approach to logging. I personally think they're all just about the same; the only real best practice is using one system.
> I have always just used java.util.logging since it is built into Java 1.4+. Commons Logging offers an extra layer of abstraction and lets you switch between java.util.logging and log4j underneath. That's cool, but I've not found it compelling enough to want to add another layer and another .jar file.
> But, I guess log4j is present because hadoop uses it directly? The .jar seems to have a dependency on it.
> In that case maybe we are better off using Commons Logging to let us integrate with log4j logging that Hadoop uses, and leave open the possibility of other callers using java.util.logging underneath.
> If that's cool I can switch my code to use Commons Logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAHOUT-52) Standardize on java.util.logging,
Commons Logging, log4j?
Posted by "Lukas Vlcek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAHOUT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596197#action_12596197 ]
Lukas Vlcek commented on MAHOUT-52:
-----------------------------------
I am not a commiter so you can totaly ignore my comment especially when it comes to logging frameworks war.
Anyway, my ignorant comments:
Logging IS IMPORTANT because in most cases it is the only way how to get useful information when it comes to bug hunting.
You should not underestimate this and your choice should not be driven by bad examples (does learning from project which uses three different logging approaches make sense?!).
Performance of logging framework DOES MATTER! Ease of use as well.
Do you want the developer to be responsible for checking if logging level is enabled?
> if (log.isDebugEnabled()) {log.debug("blah..." + localVariable)} // do you always check if level is enabled?
Do you want the developer to effectively think about construction of logging messages?
> log.debug("Now it is " + new java.util.Date() + " and this is " + i + " iteration"); // obviously bad example
If I could vote, I would pick SLF4J. Not only it is flexible (JCM is flexible enough as well I think) but it can give you a performance boost with no higher coding effort. Also read this: http://radio.weblogs.com/0122027/2003/08/15.html about when it is not good practice to use JCM.
Is having one or two more jar files really a big problem? Why Mahout couldn't be a project with good (and innovative) logging coding standards? Delivering of unit tests with every new piece of code is de facto standard - why not to require also high quality in using logging system as well? Think about this - it is not a minor matter.
> Standardize on java.util.logging, Commons Logging, log4j?
> ---------------------------------------------------------
>
> Key: MAHOUT-52
> URL: https://issues.apache.org/jira/browse/MAHOUT-52
> Project: Mahout
> Issue Type: Improvement
> Reporter: Sean Owen
> Priority: Minor
>
> I see the log4j and Commons Logging .jars in the lib/ directory. log4j isn't used; Commons Logging is used in one class (Parametered). My code just used java.util.logging directly.
> I figure we should standardize on one approach to logging. I personally think they're all just about the same; the only real best practice is using one system.
> I have always just used java.util.logging since it is built into Java 1.4+. Commons Logging offers an extra layer of abstraction and lets you switch between java.util.logging and log4j underneath. That's cool, but I've not found it compelling enough to want to add another layer and another .jar file.
> But, I guess log4j is present because hadoop uses it directly? The .jar seems to have a dependency on it.
> In that case maybe we are better off using Commons Logging to let us integrate with log4j logging that Hadoop uses, and leave open the possibility of other callers using java.util.logging underneath.
> If that's cool I can switch my code to use Commons Logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAHOUT-52) Standardize on java.util.logging,
Commons Logging, log4j?
Posted by "Sean Owen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAHOUT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596586#action_12596586 ]
Sean Owen commented on MAHOUT-52:
---------------------------------
Ted gave a +1 on the email thread. I implemented this for my code.
I suppose it's cool to replace the use of Commons Logging, and System.out.println, with SLF4J? The only exception I can imagine is simple System.out statements in the main() method of a class that is intended to be a command-line utility.
> Standardize on java.util.logging, Commons Logging, log4j?
> ---------------------------------------------------------
>
> Key: MAHOUT-52
> URL: https://issues.apache.org/jira/browse/MAHOUT-52
> Project: Mahout
> Issue Type: Improvement
> Reporter: Sean Owen
> Priority: Minor
>
> I see the log4j and Commons Logging .jars in the lib/ directory. log4j isn't used; Commons Logging is used in one class (Parametered). My code just used java.util.logging directly.
> I figure we should standardize on one approach to logging. I personally think they're all just about the same; the only real best practice is using one system.
> I have always just used java.util.logging since it is built into Java 1.4+. Commons Logging offers an extra layer of abstraction and lets you switch between java.util.logging and log4j underneath. That's cool, but I've not found it compelling enough to want to add another layer and another .jar file.
> But, I guess log4j is present because hadoop uses it directly? The .jar seems to have a dependency on it.
> In that case maybe we are better off using Commons Logging to let us integrate with log4j logging that Hadoop uses, and leave open the possibility of other callers using java.util.logging underneath.
> If that's cool I can switch my code to use Commons Logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (MAHOUT-52) Standardize on java.util.logging, Commons Logging, log4j?
Posted by Grant Ingersoll <gs...@apache.org>.
On May 11, 2008, at 6:11 PM, Sean Owen (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/MAHOUT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595942
> #action_12595942 ]
>
> Sean Owen commented on MAHOUT-52:
> ---------------------------------
>
> (Responding to Grant's email here where he notes some possible
> issues with commons logging, wonders if we should use log4j of SLF4J)
>
> I looked closer at the Hadoop source and, oh no, it uses all three.
> Actually, looks like it is mostly commons logging, with a dash of
> log4j in some places and some java.util.logging in the Eclipse
> integration. So I think the story there is "they use commons logging".
OK, if Hadoop uses Commons then let's just do that, or at least
that's my vote.
[jira] Commented: (MAHOUT-52) Standardize on java.util.logging,
Commons Logging, log4j?
Posted by "Sean Owen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAHOUT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595942#action_12595942 ]
Sean Owen commented on MAHOUT-52:
---------------------------------
(Responding to Grant's email here where he notes some possible issues with commons logging, wonders if we should use log4j of SLF4J)
I looked closer at the Hadoop source and, oh no, it uses all three. Actually, looks like it is mostly commons logging, with a dash of log4j in some places and some java.util.logging in the Eclipse integration. So I think the story there is "they use commons logging".
Really, there are issues with commons logging? I wonder what the classloader issue could be, and if it affects us?
So we have that possible strike against it, my preference to not use an extra layer of abstraction too. But Hadoop is using it and it does grant some flexibility.
For the same reason I suppose I am not terribly keen on the idea of SLF4J -- what does a logging system on top of a logging system buy you? there's the flexibility argument, but the same might be said of the more standard commons logging. SLF4J seems less likely to be used, between these two facade systems.
Then we are down to log4j vs. java.util.logging. It's personal taste but I find log4j's code and API ugly, and it's an extra .jar file. Then again java.util.logging has its own bizarrness. They are really about the same, I could go either way. I have a slight preference for java.util.logging because of its de facto status and because I have a couple thousand lines of code that use it already.
Oh boy, a vote? I don't know what the best way is to solve this, but best to do it sooner than later. Right now there are some System.out lines in the code and that's definitely suboptimal.
> Standardize on java.util.logging, Commons Logging, log4j?
> ---------------------------------------------------------
>
> Key: MAHOUT-52
> URL: https://issues.apache.org/jira/browse/MAHOUT-52
> Project: Mahout
> Issue Type: Improvement
> Reporter: Sean Owen
> Priority: Minor
>
> I see the log4j and Commons Logging .jars in the lib/ directory. log4j isn't used; Commons Logging is used in one class (Parametered). My code just used java.util.logging directly.
> I figure we should standardize on one approach to logging. I personally think they're all just about the same; the only real best practice is using one system.
> I have always just used java.util.logging since it is built into Java 1.4+. Commons Logging offers an extra layer of abstraction and lets you switch between java.util.logging and log4j underneath. That's cool, but I've not found it compelling enough to want to add another layer and another .jar file.
> But, I guess log4j is present because hadoop uses it directly? The .jar seems to have a dependency on it.
> In that case maybe we are better off using Commons Logging to let us integrate with log4j logging that Hadoop uses, and leave open the possibility of other callers using java.util.logging underneath.
> If that's cool I can switch my code to use Commons Logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.