You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pig.apache.org by Benjamin Francisoud <be...@joost.com> on 2008/01/25 17:38:16 UTC
Logging
Hi,
While reading the ProposedRoadMap [1], I found the "Logging" item
important and easy to fix ;)
I'd like to provide a patch for this but the "Current Situation" chapter
and what I've seen in the code [2] seems to say that you guys should use
log4j.
Using log4j is perfeclty fine (I used it on several project since 2002)
but making all pig class actually depend on the log4j api would be a bad
idea :(
Without any extra effort, you can use the "wonderful" commons logging
abstraction api ;)
Advantages you would get by using commons logging api:
- Making it possible to stwich from log4j, simple log or any logger of
your choice implementing the common logging api.
- Allow pig users to use the logging system of there choice if, for
example, the developped there own internal commons logging impl (not my
case currently but worked for a company where they did just that)
- You wouldn't need to add another layer of indirection in
PigLogger.java, reducing amount of code and maintenance
- If you decide to change the logging impl the java classes will not
need to by modify
You simply have to add this line of code to you classes:
private Log log = LogFactory.getLog(Foo.class);
if log4j jar is in the classpath and it finds a log4j.properties it
will use log4j at runtime...
It a configuration example, log4j can be configured in many
non-intrusive ways...
You can read the reason why I'm not using static in this example at
StaticLog wiki page [3]
I created a page to hold this dicussion result on the wiki [4]
[1] http://wiki.apache.org/pig/ProposedRoadMap
[2]
http://svn.apache.org/repos/asf/incubator/pig/trunk/src/org/apache/pig/impl/util/PigLogger.java
[3] http://wiki.apache.org/jakarta-commons/Logging/StaticLog
[4] http://wiki.apache.org/pig/LoggingPolicy
cheers
--
Benjamin Francisoud
Re: Logging
Posted by Benjamin Francisoud <be...@joost.com>.
I know logging can easily become a "religious debat" but I think
everyone will agree using "System.out.println" isn't the best solution
either ;)
You (the pig team) could vote for it, you are the one who will use it in
the end:
1- java logging
2- commons logging (+log4j)
3- sl4j
If you pick the wrong solution, making a search/replace won't be "that"
difficult anyway.
My personnal opinion (but I don't include myself in the vote) is for
commons logging
- easy to use
- I've been happy with it on previous project (except classloader
problems to find conf files but that's not related to the logging system)
- it's already use in hadoop
You can see "Commons Logging FUD" [3] for more details.
I didn't pick java logging just because I don't know anyone who is using
it that doesn't give me confidence in it....
I didn't pick slf4j because the api seems over-engeneered [1], I don't
like the "{}" in the example [2] (printf style is ok, it's just a matter
of taste here), it's less use, apparently the "swapping impl jar" thing
is on the commons logging 2.0 roadmap... but I never used it.
But you can safely ignore those arguments. As long as you pick something
I'll be happy :D
[1] http://www.slf4j.org/api/org/slf4j/Logger.html
[2] http://www.slf4j.org/manual.html
[3] http://wiki.apache.org/commons/Commons_Logging_FUD
Torsten Curdt a écrit :
>
> On 28.01.2008, at 18:56, Eric Baldeschwieler wrote:
>
>> Why not java native logging. It has come a long way.
>
> Has it arrived? Seriously - I only hear bad things about it. But never
> used it myself.
>
>> We keep working around the limitations of commons logging in Hadoop.
>> We break abstraction and use log4j commands to change logging levels
>> at run-time and such.
>
> Well, if configuration is required then is does not make much sense to
> keep an abstraction ...unless you abstract the configuration away and
> provide different implementations.
>
>> Commons logging also imports assumptions about configuration, right?
>> IE a separate XML file?
>
> CL only makes the assumption that the underlying log library has been
> configured. The XML file you are referring to is (mainly) to configure
> what Log implementation to use.
>
> cheers
> --
> Torsten
Re: Logging
Posted by Torsten Curdt <tc...@apache.org>.
On 28.01.2008, at 18:56, Eric Baldeschwieler wrote:
> Why not java native logging. It has come a long way.
Has it arrived? Seriously - I only hear bad things about it. But
never used it myself.
> We keep working around the limitations of commons logging in
> Hadoop. We break abstraction and use log4j commands to change
> logging levels at run-time and such.
Well, if configuration is required then is does not make much sense
to keep an abstraction ...unless you abstract the configuration away
and provide different implementations.
> Commons logging also imports assumptions about configuration,
> right? IE a separate XML file?
CL only makes the assumption that the underlying log library has been
configured. The XML file you are referring to is (mainly) to
configure what Log implementation to use.
cheers
--
Torsten
Re: Logging
Posted by Alan Gates <ga...@yahoo-inc.com>.
> Commons logging also imports assumptions about configuration, right?
> IE a separate XML file?
From looking over their documentation
(http://commons.apache.org/logging/guide.html#Configuration), it looked
like you could set just one properties value. Is that not correct?
Alan.
>
> <snip>
Re: Logging
Posted by Eric Baldeschwieler <er...@yahoo-inc.com>.
Why not java native logging. It has come a long way.
We keep working around the limitations of commons logging in Hadoop.
We break abstraction and use log4j commands to change logging levels
at run-time and such.
Commons logging also imports assumptions about configuration, right?
IE a separate XML file?
On Jan 28, 2008, at 12:45 AM, Benjamin Francisoud wrote:
> Ted Dunning a écrit :
>> You may also want to consider SLF4J to simplify the dependencies
>> even more.
>>
>>
> Yes never used it before could be the opportunity to learn it :)
>
> Is it what you'd like to use ? the rest of the team also ?
> Just don't want to make a patch if nobody is going to use it ;)
>
>
>> On 1/25/08 8:38 AM, "Benjamin Francisoud"
>> <be...@joost.com>
>> wrote:
>>
>>
>>> Hi,
>>>
>>> While reading the ProposedRoadMap [1], I found the "Logging" item
>>> important and easy to fix ;)
>>>
>>> I'd like to provide a patch for this but the "Current Situation"
>>> chapter
>>> and what I've seen in the code [2] seems to say that you guys
>>> should use
>>> log4j.
>>> Using log4j is perfeclty fine (I used it on several project since
>>> 2002)
>>> but making all pig class actually depend on the log4j api would
>>> be a bad
>>> idea :(
>>> Without any extra effort, you can use the "wonderful" commons
>>> logging
>>> abstraction api ;)
>>>
>>> Advantages you would get by using commons logging api:
>>> - Making it possible to stwich from log4j, simple log or any
>>> logger of
>>> your choice implementing the common logging api.
>>> - Allow pig users to use the logging system of there choice if, for
>>> example, the developped there own internal commons logging impl
>>> (not my
>>> case currently but worked for a company where they did just that)
>>> - You wouldn't need to add another layer of indirection in
>>> PigLogger.java, reducing amount of code and maintenance
>>> - If you decide to change the logging impl the java classes will not
>>> need to by modify
>>>
>>> You simply have to add this line of code to you classes:
>>>
>>> private Log log = LogFactory.getLog(Foo.class);
>>>
>>>
>>> if log4j jar is in the classpath and it finds a log4j.properties it
>>> will use log4j at runtime...
>>> It a configuration example, log4j can be configured in many
>>> non-intrusive ways...
>>>
>>> You can read the reason why I'm not using static in this example at
>>> StaticLog wiki page [3]
>>>
>>> I created a page to hold this dicussion result on the wiki [4]
>>>
>>> [1] http://wiki.apache.org/pig/ProposedRoadMap
>>> [2] http://svn.apache.org/repos/asf/incubator/pig/trunk/src/org/
>>> apache/pig/impl/ut
>>> il/PigLogger.java
>>> [3] http://wiki.apache.org/jakarta-commons/Logging/StaticLog
>>> [4] http://wiki.apache.org/pig/LoggingPolicy
>>>
>>>
>>> cheers
>>> --
>>> Benjamin Francisoud
>>>
>>
>>
>
Re: Logging
Posted by Benjamin Francisoud <be...@joost.com>.
Ted Dunning a écrit :
> You may also want to consider SLF4J to simplify the dependencies even more.
>
>
Yes never used it before could be the opportunity to learn it :)
Is it what you'd like to use ? the rest of the team also ?
Just don't want to make a patch if nobody is going to use it ;)
> On 1/25/08 8:38 AM, "Benjamin Francisoud" <be...@joost.com>
> wrote:
>
>
>> Hi,
>>
>> While reading the ProposedRoadMap [1], I found the "Logging" item
>> important and easy to fix ;)
>>
>> I'd like to provide a patch for this but the "Current Situation" chapter
>> and what I've seen in the code [2] seems to say that you guys should use
>> log4j.
>> Using log4j is perfeclty fine (I used it on several project since 2002)
>> but making all pig class actually depend on the log4j api would be a bad
>> idea :(
>> Without any extra effort, you can use the "wonderful" commons logging
>> abstraction api ;)
>>
>> Advantages you would get by using commons logging api:
>> - Making it possible to stwich from log4j, simple log or any logger of
>> your choice implementing the common logging api.
>> - Allow pig users to use the logging system of there choice if, for
>> example, the developped there own internal commons logging impl (not my
>> case currently but worked for a company where they did just that)
>> - You wouldn't need to add another layer of indirection in
>> PigLogger.java, reducing amount of code and maintenance
>> - If you decide to change the logging impl the java classes will not
>> need to by modify
>>
>> You simply have to add this line of code to you classes:
>>
>> private Log log = LogFactory.getLog(Foo.class);
>>
>>
>> if log4j jar is in the classpath and it finds a log4j.properties it
>> will use log4j at runtime...
>> It a configuration example, log4j can be configured in many
>> non-intrusive ways...
>>
>> You can read the reason why I'm not using static in this example at
>> StaticLog wiki page [3]
>>
>> I created a page to hold this dicussion result on the wiki [4]
>>
>> [1] http://wiki.apache.org/pig/ProposedRoadMap
>> [2]
>> http://svn.apache.org/repos/asf/incubator/pig/trunk/src/org/apache/pig/impl/ut
>> il/PigLogger.java
>> [3] http://wiki.apache.org/jakarta-commons/Logging/StaticLog
>> [4] http://wiki.apache.org/pig/LoggingPolicy
>>
>>
>> cheers
>> --
>> Benjamin Francisoud
>>
>
>
Re: Logging
Posted by Ted Dunning <td...@veoh.com>.
You may also want to consider SLF4J to simplify the dependencies even more.
On 1/25/08 8:38 AM, "Benjamin Francisoud" <be...@joost.com>
wrote:
> Hi,
>
> While reading the ProposedRoadMap [1], I found the "Logging" item
> important and easy to fix ;)
>
> I'd like to provide a patch for this but the "Current Situation" chapter
> and what I've seen in the code [2] seems to say that you guys should use
> log4j.
> Using log4j is perfeclty fine (I used it on several project since 2002)
> but making all pig class actually depend on the log4j api would be a bad
> idea :(
> Without any extra effort, you can use the "wonderful" commons logging
> abstraction api ;)
>
> Advantages you would get by using commons logging api:
> - Making it possible to stwich from log4j, simple log or any logger of
> your choice implementing the common logging api.
> - Allow pig users to use the logging system of there choice if, for
> example, the developped there own internal commons logging impl (not my
> case currently but worked for a company where they did just that)
> - You wouldn't need to add another layer of indirection in
> PigLogger.java, reducing amount of code and maintenance
> - If you decide to change the logging impl the java classes will not
> need to by modify
>
> You simply have to add this line of code to you classes:
>
> private Log log = LogFactory.getLog(Foo.class);
>
>
> if log4j jar is in the classpath and it finds a log4j.properties it
> will use log4j at runtime...
> It a configuration example, log4j can be configured in many
> non-intrusive ways...
>
> You can read the reason why I'm not using static in this example at
> StaticLog wiki page [3]
>
> I created a page to hold this dicussion result on the wiki [4]
>
> [1] http://wiki.apache.org/pig/ProposedRoadMap
> [2]
> http://svn.apache.org/repos/asf/incubator/pig/trunk/src/org/apache/pig/impl/ut
> il/PigLogger.java
> [3] http://wiki.apache.org/jakarta-commons/Logging/StaticLog
> [4] http://wiki.apache.org/pig/LoggingPolicy
>
>
> cheers
> --
> Benjamin Francisoud