You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simone Tripodi <si...@apache.org> on 2011/07/28 21:19:22 UTC
[logging] logging vs slf4j
Hi all guys,
I remember I raw a thread - not sure if I did it here at commons or
somewhere else here at apache - where specified we prefer adding
[logging] as components dependency instead of slf4j...
Did I just get crazy or someone can point me to the right direction please? :)
Many thanks in advance, all the best!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Christian Grobmeier <gr...@gmail.com>.
On Fri, Jul 29, 2011 at 10:33 AM, Torsten Curdt <tc...@vafer.org> wrote:
> At some stage I started to refactor commons logging into a multi
> module maven project and got rid of the discovery part. So you would
> have the commons-logging-api jar plus exactly one of the
> implementation bridges. So you pick the logging target by putting the
> correct bridge into your classpath. Similar to slf4j.
>
> Didn't think there is still interest in commons logging. Not sure I
> still have the code. I lost interest after yet another logging
> discussion :) ...but it shouldn't be hard to re-create. Not sure there
> is still enough interest in this.
To be honest, I would love to see this. I like log4j/commons-logging
very much, but there has been decreasing development effort the past
years and slf4j/logback grew strong. Finally I though at least
commons-logging is dead.
I prefer asf libs, and so I would love to see your changes. This
surely would help to revive the loggings project, which already is
resurrecting due to Ralphs efforts with Log4j 2.
So my interest is here, but I am not sure if I have enough time left
to give the support it deserves :-)
Cheers
Christian
>>>> Seems to me you should focus on making Log4J the impl
>>>> excellent
>
> That sounds like work ;)
>
>> Unfortunately, SLF4J and Logback are run under the BDFL model, not a collaboration as is done at the ASF.
>
> Which is one of the reasons I have always been very reluctant to use it.
>
> cheers,
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://www.grobmeier.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Mark Struberg <st...@yahoo.de>.
Folks, I' suggest the following:
1.) create single JARs which exactly do what they should.
2.) use the maven-shade-plugin [1] to package 'bundles' containing some fitting jars of your project just for convenience.
LieGrue,
strub
[1] http://maven.apache.org/plugins/maven-shade-plugin/
--- On Fri, 7/29/11, Ralph Goers <ra...@dslextreme.com> wrote:
> From: Ralph Goers <ra...@dslextreme.com>
> Subject: Re: [logging] logging vs slf4j
> To: "Commons Developers List" <de...@commons.apache.org>
> Date: Friday, July 29, 2011, 5:39 PM
> Unfortunately, you are in the
> minority on this one. Technically, you could just use the
> Log4J 2.0 Impl jar, but then you would be coding to a
> private API.
>
> Ralph
>
> On Jul 29, 2011, at 8:15 AM, Gary Gregory wrote:
>
> > One thing that is a hassle to me with modularized
> projects, even
> > slf4j, is that you end up with a bunch of tiny jars.
> IOW & IMO: a
> > mess. Personally, I want one jar to rule them all. If
> I want to switch
> > logging implementer or a client wants another impl I
> have to fiddle
> > with my builds and explain what each jar does. It's a
> hassle.
> >
> > Gary
> >
> > On Fri, Jul 29, 2011 at 4:33 AM, Torsten Curdt <tc...@vafer.org>
> wrote:
> >> At some stage I started to refactor commons
> logging into a multi
> >> module maven project and got rid of the discovery
> part. So you would
> >> have the commons-logging-api jar plus exactly one
> of the
> >> implementation bridges. So you pick the logging
> target by putting the
> >> correct bridge into your classpath. Similar to
> slf4j.
> >>
> >> Didn't think there is still interest in commons
> logging. Not sure I
> >> still have the code. I lost interest after yet
> another logging
> >> discussion :) ...but it shouldn't be hard to
> re-create. Not sure there
> >> is still enough interest in this.
> >>
> >>>>> Seems to me you should focus on making
> Log4J the impl
> >>>>> excellent
> >>
> >> That sounds like work ;)
> >>
> >>> Unfortunately, SLF4J and Logback are run under
> the BDFL model, not a collaboration as is done at the ASF.
> >>
> >> Which is one of the reasons I have always been
> very reluctant to use it.
> >>
> >> cheers,
> >> Torsten
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Thank you,
> > Gary
> >
> > http://garygregory.wordpress.com/
> > http://garygregory.com/
> > http://people.apache.org/~ggregory/
> > http://twitter.com/GaryGregory
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
Unfortunately, you are in the minority on this one. Technically, you could just use the Log4J 2.0 Impl jar, but then you would be coding to a private API.
Ralph
On Jul 29, 2011, at 8:15 AM, Gary Gregory wrote:
> One thing that is a hassle to me with modularized projects, even
> slf4j, is that you end up with a bunch of tiny jars. IOW & IMO: a
> mess. Personally, I want one jar to rule them all. If I want to switch
> logging implementer or a client wants another impl I have to fiddle
> with my builds and explain what each jar does. It's a hassle.
>
> Gary
>
> On Fri, Jul 29, 2011 at 4:33 AM, Torsten Curdt <tc...@vafer.org> wrote:
>> At some stage I started to refactor commons logging into a multi
>> module maven project and got rid of the discovery part. So you would
>> have the commons-logging-api jar plus exactly one of the
>> implementation bridges. So you pick the logging target by putting the
>> correct bridge into your classpath. Similar to slf4j.
>>
>> Didn't think there is still interest in commons logging. Not sure I
>> still have the code. I lost interest after yet another logging
>> discussion :) ...but it shouldn't be hard to re-create. Not sure there
>> is still enough interest in this.
>>
>>>>> Seems to me you should focus on making Log4J the impl
>>>>> excellent
>>
>> That sounds like work ;)
>>
>>> Unfortunately, SLF4J and Logback are run under the BDFL model, not a collaboration as is done at the ASF.
>>
>> Which is one of the reasons I have always been very reluctant to use it.
>>
>> cheers,
>> Torsten
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Gary Gregory <ga...@gmail.com>.
One thing that is a hassle to me with modularized projects, even
slf4j, is that you end up with a bunch of tiny jars. IOW & IMO: a
mess. Personally, I want one jar to rule them all. If I want to switch
logging implementer or a client wants another impl I have to fiddle
with my builds and explain what each jar does. It's a hassle.
Gary
On Fri, Jul 29, 2011 at 4:33 AM, Torsten Curdt <tc...@vafer.org> wrote:
> At some stage I started to refactor commons logging into a multi
> module maven project and got rid of the discovery part. So you would
> have the commons-logging-api jar plus exactly one of the
> implementation bridges. So you pick the logging target by putting the
> correct bridge into your classpath. Similar to slf4j.
>
> Didn't think there is still interest in commons logging. Not sure I
> still have the code. I lost interest after yet another logging
> discussion :) ...but it shouldn't be hard to re-create. Not sure there
> is still enough interest in this.
>
>>>> Seems to me you should focus on making Log4J the impl
>>>> excellent
>
> That sounds like work ;)
>
>> Unfortunately, SLF4J and Logback are run under the BDFL model, not a collaboration as is done at the ASF.
>
> Which is one of the reasons I have always been very reluctant to use it.
>
> cheers,
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Torsten Curdt <tc...@vafer.org>.
At some stage I started to refactor commons logging into a multi
module maven project and got rid of the discovery part. So you would
have the commons-logging-api jar plus exactly one of the
implementation bridges. So you pick the logging target by putting the
correct bridge into your classpath. Similar to slf4j.
Didn't think there is still interest in commons logging. Not sure I
still have the code. I lost interest after yet another logging
discussion :) ...but it shouldn't be hard to re-create. Not sure there
is still enough interest in this.
>>> Seems to me you should focus on making Log4J the impl
>>> excellent
That sounds like work ;)
> Unfortunately, SLF4J and Logback are run under the BDFL model, not a collaboration as is done at the ASF.
Which is one of the reasons I have always been very reluctant to use it.
cheers,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Simone Tripodi <si...@apache.org>.
great news Ralph, and kudos for your hard work!
looking forward to hear more from log4j soon!
have a nice day, all the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Jul 29, 2011 at 5:53 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> Oh - I should have also mentioned that I implemented support for the SLF4J API and commons logging as well as the new Log4J API.
>
> Ralph
>
> On Jul 28, 2011, at 7:30 PM, Henri Yandell wrote:
>
>> Random input. Seems to me you should focus on making Log4J the impl
>> excellent and not trying to create yet.another.facade. ie) Don't
>> compete with SLF4J, compete with Logback (given its licensing).
>>
>> Hen
>>
>> On Thu, Jul 28, 2011 at 5:25 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>> FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work.
>>>
>>> Ralph
>>>
>>> [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/
>>>
>>>
>>> On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote:
>>>
>>>> Personally I'm happy for commons-logging to die. :)
>>>>
>>>> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi
>>>> <si...@apache.org> wrote:
>>>>> Hi all guys,
>>>>> I remember I raw a thread - not sure if I did it here at commons orI
>>>>> somewhere else here at apache - where specified we prefer adding
>>>>> [logging] as components dependency instead of slf4j...
>>>>> Did I just get crazy or someone can point me to the right direction please? :)
>>>>> Many thanks in advance, all the best!!!
>>>>> Simo
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://www.99soft.org/
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
Oh - I should have also mentioned that I implemented support for the SLF4J API and commons logging as well as the new Log4J API.
Ralph
On Jul 28, 2011, at 7:30 PM, Henri Yandell wrote:
> Random input. Seems to me you should focus on making Log4J the impl
> excellent and not trying to create yet.another.facade. ie) Don't
> compete with SLF4J, compete with Logback (given its licensing).
>
> Hen
>
> On Thu, Jul 28, 2011 at 5:25 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>> FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work.
>>
>> Ralph
>>
>> [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/
>>
>>
>> On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote:
>>
>>> Personally I'm happy for commons-logging to die. :)
>>>
>>> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi
>>> <si...@apache.org> wrote:
>>>> Hi all guys,
>>>> I remember I raw a thread - not sure if I did it here at commons orI
>>>> somewhere else here at apache - where specified we prefer adding
>>>> [logging] as components dependency instead of slf4j...
>>>> Did I just get crazy or someone can point me to the right direction please? :)
>>>> Many thanks in advance, all the best!!!
>>>> Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://www.99soft.org/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
Commons Logging takes a least common denominator approach, which makes it useful for only fairly simple use cases. The goals for Log4J 2 are much more extensive than just a simple API that wraps other logging frameworks.
Ralph
On Jul 29, 2011, at 6:19 AM, Paul Benedict wrote:
> Would there be any merit in combining the log4j and commons logging
> code? Given a hypothetical Log4j 2 and JCL 2, how much different could
> they really be in terms of their goals and add-ins?
>
> On Fri, Jul 29, 2011 at 4:51 AM, Gilles Sadowski
> <gi...@harfang.homelinux.org> wrote:
>> Hello.
>>
>>> I would have done that but some of the deficiencies are in the API and I couldn't get Ceki to incorporate them.
>>
>> Do you have a pointer to a listing of those deficiencies?
>>
>>> [...]
>>
>>
>> Thanks,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Paul Benedict <pb...@apache.org>.
Would there be any merit in combining the log4j and commons logging
code? Given a hypothetical Log4j 2 and JCL 2, how much different could
they really be in terms of their goals and add-ins?
On Fri, Jul 29, 2011 at 4:51 AM, Gilles Sadowski
<gi...@harfang.homelinux.org> wrote:
> Hello.
>
>> I would have done that but some of the deficiencies are in the API and I couldn't get Ceki to incorporate them.
>
> Do you have a pointer to a listing of those deficiencies?
>
>> [...]
>
>
> Thanks,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
The major issue I had was https://issues.apache.org/jira/browse/LOG4J2-31. We currently use SLF4J for audit logging via the SLF4J extension's EventLogger and EventData. Unfortunately, SLF4J has to convert the EventData object to XML since SLF4J/Logback don't provide a good way of handling this. To use this I had to create a Layout "wrapper" to convert the XML back to an EventData object so it could be used in various components. Needless to say this is cumbersome, slow and error prone.
The Log4J 2.0 API uses a Message interface for everything. This allows the caller to have much more control over the formatting of the objects without having to write complex layouts that check for the presence of certain types of objects as parameters (which they can still do of course).
Ralph
On Jul 29, 2011, at 2:51 AM, Gilles Sadowski wrote:
> Hello.
>
>> I would have done that but some of the deficiencies are in the API and I couldn't get Ceki to incorporate them.
>
> Do you have a pointer to a listing of those deficiencies?
>
>> [...]
>
>
> Thanks,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [logging] logging vs slf4j
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> I would have done that but some of the deficiencies are in the API and I couldn't get Ceki to incorporate them.
Do you have a pointer to a listing of those deficiencies?
> [...]
Thanks,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
I would have done that but some of the deficiencies are in the API and I couldn't get Ceki to incorporate them. Unfortunately, SLF4J and Logback are run under the BDFL model, not a collaboration as is done at the ASF.
Ralph
On Jul 28, 2011, at 7:30 PM, Henri Yandell wrote:
> Random input. Seems to me you should focus on making Log4J the impl
> excellent and not trying to create yet.another.facade. ie) Don't
> compete with SLF4J, compete with Logback (given its licensing).
>
> Hen
>
> On Thu, Jul 28, 2011 at 5:25 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>> FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work.
>>
>> Ralph
>>
>> [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/
>>
>>
>> On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote:
>>
>>> Personally I'm happy for commons-logging to die. :)
>>>
>>> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi
>>> <si...@apache.org> wrote:
>>>> Hi all guys,
>>>> I remember I raw a thread - not sure if I did it here at commons orI
>>>> somewhere else here at apache - where specified we prefer adding
>>>> [logging] as components dependency instead of slf4j...
>>>> Did I just get crazy or someone can point me to the right direction please? :)
>>>> Many thanks in advance, all the best!!!
>>>> Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://www.99soft.org/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Henri Yandell <fl...@gmail.com>.
Random input. Seems to me you should focus on making Log4J the impl
excellent and not trying to create yet.another.facade. ie) Don't
compete with SLF4J, compete with Logback (given its licensing).
Hen
On Thu, Jul 28, 2011 at 5:25 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work.
>
> Ralph
>
> [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/
>
>
> On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote:
>
>> Personally I'm happy for commons-logging to die. :)
>>
>> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi
>> <si...@apache.org> wrote:
>>> Hi all guys,
>>> I remember I raw a thread - not sure if I did it here at commons orI
>>> somewhere else here at apache - where specified we prefer adding
>>> [logging] as components dependency instead of slf4j...
>>> Did I just get crazy or someone can point me to the right direction please? :)
>>> Many thanks in advance, all the best!!!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Gary Gregory <ga...@gmail.com>.
Great news Ralph. I look forward to the new version.
Gary
On Jul 28, 2011, at 20:26, Ralph Goers <ra...@dslextreme.com> wrote:
> FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work.
>
> Ralph
>
> [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/
>
>
> On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote:
>
>> Personally I'm happy for commons-logging to die. :)
>>
>> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi
>> <si...@apache.org> wrote:
>>> Hi all guys,
>>> I remember I raw a thread - not sure if I did it here at commons orI
>>> somewhere else here at apache - where specified we prefer adding
>>> [logging] as components dependency instead of slf4j...
>>> Did I just get crazy or someone can point me to the right direction please? :)
>>> Many thanks in advance, all the best!!!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
Yes, Ceki created SLF4J and Logback based on his experience with 1.2 and 1.3. The logging community is pretty small and really could use more people involved. I've had quite a bit of experience with logging for my employer as our needs are a bit different than what most people use a logging framework for. As a consequence, one of my primary focuses has been to make sure those use cases are supported, in addition to what SLF4J, Logback and Log4j do.
https://issues.apache.org/jira/browse/LOG4J2 is where all the feature requests currently reside. Log4j 1.x is in bugzilla.
Ralph
On Jul 28, 2011, at 5:39 PM, Paul Benedict wrote:
> Good deal Ralph! Didn't the creator of Log4j abandon the 1.2/1.3
> branch to make SLF4J? Anyways, I have no idea why all the creativity
> for logging went outside of Apache, but I would definitely like to see
> a version 2.0.
>
> You taking feature requests yet in JIRA? :-)
>
> Paul
>
> On Thu, Jul 28, 2011 at 7:25 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>> FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work.
>>
>> Ralph
>>
>> [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/
>>
>>
>> On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote:
>>
>>> Personally I'm happy for commons-logging to die. :)
>>>
>>> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi
>>> <si...@apache.org> wrote:
>>>> Hi all guys,
>>>> I remember I raw a thread - not sure if I did it here at commons orI
>>>> somewhere else here at apache - where specified we prefer adding
>>>> [logging] as components dependency instead of slf4j...
>>>> Did I just get crazy or someone can point me to the right direction please? :)
>>>> Many thanks in advance, all the best!!!
>>>> Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://www.99soft.org/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [logging] logging vs slf4j
Posted by Paul Benedict <pb...@apache.org>.
Good deal Ralph! Didn't the creator of Log4j abandon the 1.2/1.3
branch to make SLF4J? Anyways, I have no idea why all the creativity
for logging went outside of Apache, but I would definitely like to see
a version 2.0.
You taking feature requests yet in JIRA? :-)
Paul
On Thu, Jul 28, 2011 at 7:25 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work.
>
> Ralph
>
> [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/
>
>
> On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote:
>
>> Personally I'm happy for commons-logging to die. :)
>>
>> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi
>> <si...@apache.org> wrote:
>>> Hi all guys,
>>> I remember I raw a thread - not sure if I did it here at commons orI
>>> somewhere else here at apache - where specified we prefer adding
>>> [logging] as components dependency instead of slf4j...
>>> Did I just get crazy or someone can point me to the right direction please? :)
>>> Many thanks in advance, all the best!!!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work.
Ralph
[1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/
On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote:
> Personally I'm happy for commons-logging to die. :)
>
> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi
> <si...@apache.org> wrote:
>> Hi all guys,
>> I remember I raw a thread - not sure if I did it here at commons orI
>> somewhere else here at apache - where specified we prefer adding
>> [logging] as components dependency instead of slf4j...
>> Did I just get crazy or someone can point me to the right direction please? :)
>> Many thanks in advance, all the best!!!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [logging] logging vs slf4j
Posted by Simone Tripodi <si...@apache.org>.
hahahaha :D
I asked because there's one user that proposed a [chain] evolution,
and one of suggested improvements is migrating over slf4j - I
(wrongly, maybe) suggested to keep [logging] because here at commons
we continue using it but, as said, I maybe reported a wrong fact.
Do we encourage such kind of migrations or we are more conservative?
Many thanks in advance, all the best!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Thu, Jul 28, 2011 at 10:01 PM, Henri Yandell <fl...@gmail.com> wrote:
> Personally I'm happy for commons-logging to die. :)
>
> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi
> <si...@apache.org> wrote:
>> Hi all guys,
>> I remember I raw a thread - not sure if I did it here at commons or
>> somewhere else here at apache - where specified we prefer adding
>> [logging] as components dependency instead of slf4j...
>> Did I just get crazy or someone can point me to the right direction please? :)
>> Many thanks in advance, all the best!!!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Chris Pratt <th...@gmail.com>.
Personally, I'd have to disagree, choosing an inferior logging engine just
because you don't have to add an additional jar file to you're war file is
bad reasoning. SLF4j is a very thin API that leaves the decision of logging
engine to the implementor, which is where it belongs.
(*Chris*)
On Aug 7, 2011 1:35 AM, "Jochen Wiedmann" <jo...@gmail.com> wrote:
> On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory <ga...@gmail.com>
wrote:
>
>> Or maybe Log4j 2 could replace [logging].
>
> If we really have to reconsider this stuff, then I'd propose to
>
> a) Use java.util.logging, because it doesn't require any additional
> dependencies and is guaranteed to work anywhere.
> b) Carefully document how to bridge jul to log4j, because that's
> exactly what's required in almost any application container I am aware
> of. (The exception being Tomcat, which uses jul anyways.)
> c) If the slf4j fans insist, add similar documentation for bridging
> jul to slf4j.
>
> Jochen
>
> --
> Capitalism is the astounding belief that the most wickedest of men
> will do the most wickedest of things for the greatest good of
> everyone.
>
> John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
Re: [logging] logging vs slf4j
Posted by Emmanuel Bourg <eb...@apache.org>.
+1 as well. That's the path I advocated for Configuration 2.0, combined
with the log4j bridge from Paul Smith [1]
Maybe we should stop spending our energy on alternative logging
frameworks and try to improve the standard one in the JDK instead. I
have been told that Java was open source now, so let's contribute !
Emmanuel Bourg
[1]
http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/examples.html
Le 07/08/2011 10:31, Jochen Wiedmann a écrit :
> On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory<ga...@gmail.com> wrote:
>
>> Or maybe Log4j 2 could replace [logging].
>
> If we really have to reconsider this stuff, then I'd propose to
>
> a) Use java.util.logging, because it doesn't require any additional
> dependencies and is guaranteed to work anywhere.
> b) Carefully document how to bridge jul to log4j, because that's
> exactly what's required in almost any application container I am aware
> of. (The exception being Tomcat, which uses jul anyways.)
> c) If the slf4j fans insist, add similar documentation for bridging
> jul to slf4j.
>
> Jochen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Mark Struberg <st...@yahoo.de>.
Hi Mark!
Exactly the classloader problem is what we try to solve in log4j-2.0. Tomcat is by far not the only project which suffers a lot from this shortcoming. OpenWebBeans, MyFaces, OpenJPA, etc - all projects which are usually in a shared classpath have the problem that they cannot cleanly use static Loggers in their classes. Plus jul is _not_ Serializable. With jul, you have to add 20++ lines of code to every class just to fix the most fundamental functionality fixed. In this terms jul is a single big mess...
LieGrue,
strub
--- On Sun, 8/7/11, Mark Thomas <ma...@apache.org> wrote:
> From: Mark Thomas <ma...@apache.org>
> Subject: Re: [logging] logging vs slf4j
> To: "Commons Developers List" <de...@commons.apache.org>
> Date: Sunday, August 7, 2011, 9:57 AM
> On 07/08/2011 09:31, Jochen Wiedmann
> wrote:
> > On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> >> Or maybe Log4j 2 could replace [logging].
> >
> > If we really have to reconsider this stuff, then I'd
> propose to
> >
> > a) Use java.util.logging, because it doesn't require
> any additional
> > dependencies and is guaranteed to work anywhere.
> > b) Carefully document how to bridge jul to log4j,
> because that's
> > exactly what's required in almost any application
> container I am aware
> > of. (The exception being Tomcat, which uses jul
> anyways.)
> > c) If the slf4j fans insist, add similar documentation
> for bridging
> > jul to slf4j.
>
> +1. I like this plan.
>
> As an aside, Tomcat doesn't use jul, it uses JULI which is
> a modified
> commons logging implementation hard coded to output to jul
> by default
> with an alternative Jar that is hard-coded for log4j. Why
> the
> complexity? jul is not class loader aware which is a
> problem as soon as
> web applications start declaring loggers with the same
> name.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Torsten Curdt <tc...@vafer.org>.
> The biggest issue I have with SLF4J is figuring out the dependencies
> that I need. I really detest having an API jar and then an
> implementation/bridge jar. I find that too annoying.
I cannot see how that is annoying. It's simple and it works.
What's annoying you about this?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Aug 8, 2011 at 3:23 PM, Paul Benedict <pb...@apache.org> wrote:
> On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta <ro...@fastmail.fm> wrote:
>> Perhaps I'm missing something, but what exactly is wrong with simply
>> using slf4j? It is an extremely simple, widely used library that
>> provides out of the box hooks for many logging frameworks including
>> log4j and logback, simple to configure (i.e. drop the appropriate jars
>> in and thats it), and works out of the box in an OSGi environment? The
>> only downside appears to be that it is not an Apache project. So what.
>
> The biggest issue I have with SLF4J is figuring out the dependencies
> that I need. I really detest having an API jar and then an
> implementation/bridge jar. I find that too annoying.
+1 on that. Give me one jar. Convenience please.
Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Aug 8, 2011 at 3:28 PM, Matt Benson <gu...@gmail.com> wrote:
> On Mon, Aug 8, 2011 at 2:23 PM, Paul Benedict <pb...@apache.org> wrote:
>> On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta <ro...@fastmail.fm> wrote:
>>> Perhaps I'm missing something, but what exactly is wrong with simply
>>> using slf4j? It is an extremely simple, widely used library that
>>> provides out of the box hooks for many logging frameworks including
>>> log4j and logback, simple to configure (i.e. drop the appropriate jars
>>> in and thats it), and works out of the box in an OSGi environment? The
>>> only downside appears to be that it is not an Apache project. So what.
>>
>> The biggest issue I have with SLF4J is figuring out the dependencies
>> that I need. I really detest having an API jar and then an
>> implementation/bridge jar. I find that too annoying.
>>
>
> In fairness, using a dependency manager with support for transitive
> dependencies you should only have to specify the implementation jar.
> In the case of slf4j you may have to provide multiple jars (impl +
> bridge X n logging frameworks in use throughout your application),
> however. Of course, log4j v2 will have to support this paradigm in
> some fashion or lose runtime "market share" due to slf4j's ability to
> cater to the "lowest common denominator."
Even if I Iived in OSGi-land, I'd want one jar/bundle/file. Slicing
and dicing in such a minute way seems like a lot of noise. If I were
programming for a light bulb, I might care about how big my jars get,
but I do not, so I won't ;)
Gary
>
> Matt
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Raman Gupta <ro...@fastmail.fm>.
A few comments on the list of points against slf4j below...
On 08/08/2011 05:58 PM, Elijah Zupancic wrote:
> From what I can tell from the thread, here are the following points
> against SLF4J:
>
> * Log4j developer V2 would like to see the Apache community support
> the project rather than putting resources into slf4j.
Keep in mind that slf4j is not a logging framework -- it is only a
facade that provides:
1) an API
2) (optional) bridges from jul, jcl, log4j to a target framework of choice
I think there may be some confusion with Logback. Logback is the
logging framework created by Ceki that *implements* the slf4j API, but
is a separate project and using slf4j creates no dependency on Logback.
> * Slf4j apparently has some deficiencies in its API such as: "SLF4J
> has to convert the EventData object to XML since SLF4J/Logback don't
> provide a good way of handling this."
If this is truly an API deficiency (i.e. SLF4J, not logback), then
AFAICT every other current logging API has the same deficiency,
including log4j, jul and jcl -- since they are all pretty similar.
IOW, very few users will care.
> * Log4j V2 also implements support for the Slf4j API.
Great. This is an advantage of coding commons components against slf4j
since both logback and log4j v2 can both be used out of the box with a
native implementation of the slf4j api.
> * There is a hassle with too many jars for dependencies with slf4j.
I addressed this previously. There is no alternative solution that is
simpler. If jul had been implemented as an API (like slf4j) then we'd
only need one jar. Alas...
> * Every time Ceki goes on vacation everything stops.
Again, we are talking about an API. It rarely changes. There is little
reason for it too change, and many reasons for it not to change.
> * Some have a preference for Apache driven projects.
OK.
> * Figuring out the dependencies that are needed can be difficult.
It's actually really simple. Far and away simpler than commons-logging.
For writing a library, you need one jar: slf4j-api.jar. That's it.
For developing an application, here are the dependencies in a
nutshell. This should cover every common situation. Pick your desired
situation, and put the jars specified on your classpath - done.
1) I want all log statements to go to log4j v1:
slf4j-log4j12.jar
log4j.jar
2) I want all log statements to go to log4j v2:
log4jv2.jar
(the above is a guess based on your statement that log4j v2 implements
the slf4j-api)
3) I want all log statements to go to logback:
logback-core.jar
logback-classic.jar
(optional) logback-access.jar (if logging web access logs)
4) I want all log statements to go to jul:
slf4j-jdk14.jar
5) I want all log statements to go to jcl:
slf4j-jcl.jar
For *all* of the above, add:
slf4j-api.jar
(optional) jul-to-slf4j.jar (if using libs that call jul)
(optional) jcl-over-slf4j.jar (if using libs that call jcl)
JCL only supports option #1 and #4 (I think) and uses one less jar in
those cases.
> If we can come to some consensus regarding this issues, then I think
> there will be more traction toward Slf4j.
Cool. Given the above list, I don't really see any issue with coding
commons projects against the slf4j api. Except perhaps the "it's not
made here" thing. If that is a problem, then as I said JCL is fine and
easily bridged to slf4j and thence to any desired framework.
Cheers,
Raman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Raman Gupta <ro...@fastmail.fm>.
OK. Note that -- in a similar vein to what you proposed -- I'm also
fine with simply keeping commons-logging as is. The really nice thing
about commons-logging is that it is based on an API (like SLF4j but
unlike jul!).
Therefore, it is really easy for people to do whatever they want --
e.g. for people who use slf4j, we simply ignore commons-logging.jar
and drop in jcl-over-slf4j.jar instead which implements the same jcl
API. The main annoyance is with dependency managers that don't
understand the equivalency and therefore resolve commons-logging.jar,
requiring explicit excludes. This is a manageable problem though.
Cheers,
Raman
On 08/08/2011 05:58 PM, Elijah Zupancic wrote:
> Raman,
>
> You may have proposed this earlier in the thread and I didn't catch
> it. I actually like your suggestion the best, but it seems like it is
> a difficult sell for a lot of people to compile against the slf4j API
> for a variety of reasons that are not strictly code related.
>
> My suggestion was intended to bridge the gap between the concerns
> toward compiling directly against slf4j.
>
> Another option is to try to work with Ceki to address some of the
> concerns of the commons community with regards to using slf4j.
>
> From what I can tell from the thread, here are the following points
> against SLF4J:
>
> * Log4j developer V2 would like to see the Apache community support
> the project rather than putting resources into slf4j.
> * Slf4j apparently has some deficiencies in its API such as: "SLF4J
> has to convert the EventData object to XML since SLF4J/Logback don't
> provide a good way of handling this."
> * Log4j V2 also implements support for the Slf4j API.
> * There is a hassle with too many jars for dependencies with slf4j.
> * Every time Ceki goes on vacation everything stops.
> * Some have a preference for Apache driven projects.
> * Figuring out the dependencies that are needed can be difficult.
>
> If we can come to some consensus regarding this issues, then I think
> there will be more traction toward Slf4j.
>
> Thanks,
> -Elijah
>
> On Mon, Aug 8, 2011 at 2:13 PM, Raman Gupta <ro...@fastmail.fm> wrote:
>> On 08/08/2011 04:56 PM, Elijah Zupancic wrote:
>>> This could be done by choosing (dynamically or by configuration) the
>>> logger implementation log4j / commons / slf4j / jul and then loading
>>> the LoggerFactory into a wrapper class that is then called used by the
>>> Commons project.
>>>
>>> We would then make the logger implementations a compile-time
>>> dependency only and relay upon the consumer to provide them.
>>>
>>> I do realize that this is essentially doing a Facade on top of a
>>> Facade, but it solves the problem for consumers of the library by
>>> providing many options.
>>>
>>> So, am I crazy?
>>
>> If I understand you correctly, you would have this dependency chain:
>>
>> random-commons-project ->
>> commons-logging-wrapper ->
>> API like slf4j or logging implementation (at runtime)
>>
>> Plus commons-logging-wrapper requires compile-time knowledge of all
>> possible target frameworks, since it is not coding to an API.
>>
>> Can you explain the advantage over simply coding
>> random-commons-project against slf4j-api.jar? Then, you have this
>> dependency chain:
>>
>> random-commons-project ->
>> slf4j-api ->
>> logging implementation (at runtime)
>>
>> And anyone can create their own slf4j compatible logging
>> implementation simply by implementing the slf4j api and dropping their
>> jar into their environment.
>>
>> Cheers,
>> Raman
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Simone Tripodi <si...@apache.org>.
Hi all guys!!!
sorry for joining so late the discussion (working on some stuff as
bricklayer at home!!! didn't know it is fun!)
* I don't understand why JULI should be so "complicated" to be
adopted... if in trouble, please take a look at juli-to-log4j[1] bride
written by our ASF mate Paul Smith. I'm a big fan on Google Guice and
I tend to write my tasks on work on top of JSR330 using it - it relies
100% on JULI for logging, when/if something goes wrong, I just hijack
the logging to log4j or logback. done. And believe me, if I can do it,
everybody can.
* given the previous fact, the proposed facade by slf4j reminds me
what we could already do using JULI and related bridges - please
correct me if I'm wrong, I'm sure there are missing features I'm not
aware, but I could bridge JULI to logback as well - and if omitting
the -Djava.util.logging.manager=org.apache.logging.julbridge.JULBridgeLogManager
is a so huge difference, I missed something
* Ceki, you can't immagine how much I have to be thankful to you!!!
:) I strongly respect you, your POV and what you've been doing, but I
hope there will be the chance to bring you back to the ASF :)
Have a nice day, all the best!!!
Simo
[1] http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Aug 9, 2011 at 7:16 PM, Ceki Gulcu <ce...@qos.ch> wrote:
> On 09.08.2011 11:57, Christian Grobmeier wrote:
>>>>
>>>> Another option is to try to work with Ceki to address some of the
>>>> concerns of the commons community with regards to using slf4j.
>>>>
>>>> * There is a hassle with too many jars for dependencies with slf4j.
>>>> * Every time Ceki goes on vacation everything stops.
>>>> * Some have a preference for Apache driven projects.
>>>> * Figuring out the dependencies that are needed can be difficult.
>>>
>>> Another option would be to try to convince Ceki to move his project to
>>> the ASF? He is an ASF member, right? What were his concerns about
>>> the ASF that made him start his project elsewhere?
>>
>> Ceki is an ASF member and even a Logging PMC.
>> You can read most about his concerns on his blog, for example:
>> http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html
>> http://ceki.blogspot.com/2010/05/committocracy-as-alternative-for.html
>>
>> He seems to be very opposed to the ASF model; there was much bad
>> feelings in the "log4j case" before I started with logging and
>> therefore I doubt that Ceki is willing to go back to the ASF. At least
>> his blogposts reflect that he is not satisfied with the "Apache Way"
>> itself instead of personal trouble, which we might be able to solve.
>> Ceki is reading this list, so maybe he wants to elaborate a bit more.
>
> * On the ASF model
>
> In a nutshell, while the ASF is a great organization in many ways, it
> is not a meritocracy mainly because merit is not measured at all and
> at the project level no responsiblity is accrued on merit beyond
> committership. BTW, the BDFL model is not a meritocracy
> either. Finding a good model for running organisations is no simple
> matter. The Apache model may even be better than some but it bothers
> me that the ASF misrepresents itself as a meritocracy.
>
> * On logging
>
> One of the disadvantages of a relatively large and open ecosystem such
> as Java is that you get several competing libraries solving common
> problems. Logging is a rather devisive case in point.
>
> SLF4J has deficiences with regards to modularity are imho testimony to
> the lack of a widely accepted solution to modularity in Java. In any
> case, I am unaware of a satisfactory solution. OSGi is of course one
> possible approach but OSGi is a complex beast and not that widely
> accepted (yet).
>
> As for deficiences in SLF4J API, varargs support [1] and event data
> support come to mind. Varargs support is very likely to be added in
> SLF4J 2.0. As for event data support mentioned by Ralph, the idea was
> initially proposed by Joern Huxhorn. I am not entirely convinced by
> it.
>
> However, Ralph is right to observe that had SLF4J been developped at
> the ASF and that Ralph, Joern and me were the only SLF4J
> developpers, event data support would probably be part of the SLF4J
> API. Having said that, since event data support is a little
> controversial, it might have been turned down at the ASF as well
> (assuming the involvement of more developpers who shared my lack of
> enthusiams for event data).
>
> Anyway, Ralph made some very valuable contributiuons to the logback
> project and I am sorry to see him stop. Given what I have seen of his
> work, he will surely do an excellent job with log4j v2.
>
> [1] http://bugzilla.slf4j.org/show_bug.cgi?id=31
>
> --
> Ceki
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Ceki Gulcu <ce...@qos.ch>.
On 09.08.2011 11:57, Christian Grobmeier wrote:
>>> Another option is to try to work with Ceki to address some of the
>>> concerns of the commons community with regards to using slf4j.
>>>
>>> * There is a hassle with too many jars for dependencies with slf4j.
>>> * Every time Ceki goes on vacation everything stops.
>>> * Some have a preference for Apache driven projects.
>>> * Figuring out the dependencies that are needed can be difficult.
>>
>> Another option would be to try to convince Ceki to move his project to
>> the ASF? He is an ASF member, right? What were his concerns about
>> the ASF that made him start his project elsewhere?
>
> Ceki is an ASF member and even a Logging PMC.
> You can read most about his concerns on his blog, for example:
> http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html
> http://ceki.blogspot.com/2010/05/committocracy-as-alternative-for.html
>
> He seems to be very opposed to the ASF model; there was much bad
> feelings in the "log4j case" before I started with logging and
> therefore I doubt that Ceki is willing to go back to the ASF. At least
> his blogposts reflect that he is not satisfied with the "Apache Way"
> itself instead of personal trouble, which we might be able to solve.
> Ceki is reading this list, so maybe he wants to elaborate a bit more.
* On the ASF model
In a nutshell, while the ASF is a great organization in many ways, it
is not a meritocracy mainly because merit is not measured at all and
at the project level no responsiblity is accrued on merit beyond
committership. BTW, the BDFL model is not a meritocracy
either. Finding a good model for running organisations is no simple
matter. The Apache model may even be better than some but it bothers
me that the ASF misrepresents itself as a meritocracy.
* On logging
One of the disadvantages of a relatively large and open ecosystem such
as Java is that you get several competing libraries solving common
problems. Logging is a rather devisive case in point.
SLF4J has deficiences with regards to modularity are imho testimony to
the lack of a widely accepted solution to modularity in Java. In any
case, I am unaware of a satisfactory solution. OSGi is of course one
possible approach but OSGi is a complex beast and not that widely
accepted (yet).
As for deficiences in SLF4J API, varargs support [1] and event data
support come to mind. Varargs support is very likely to be added in
SLF4J 2.0. As for event data support mentioned by Ralph, the idea was
initially proposed by Joern Huxhorn. I am not entirely convinced by
it.
However, Ralph is right to observe that had SLF4J been developped at
the ASF and that Ralph, Joern and me were the only SLF4J
developpers, event data support would probably be part of the SLF4J
API. Having said that, since event data support is a little
controversial, it might have been turned down at the ASF as well
(assuming the involvement of more developpers who shared my lack of
enthusiams for event data).
Anyway, Ralph made some very valuable contributiuons to the logback
project and I am sorry to see him stop. Given what I have seen of his
work, he will surely do an excellent job with log4j v2.
[1] http://bugzilla.slf4j.org/show_bug.cgi?id=31
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Aug 9, 2011 at 5:57 AM, Christian Grobmeier <gr...@gmail.com> wrote:
>>> Another option is to try to work with Ceki to address some of the
>>> concerns of the commons community with regards to using slf4j.
>>>
>>> * There is a hassle with too many jars for dependencies with slf4j.
>>> * Every time Ceki goes on vacation everything stops.
>>> * Some have a preference for Apache driven projects.
>>> * Figuring out the dependencies that are needed can be difficult.
>>
>> Another option would be to try to convince Ceki to move his project to
>> the ASF? He is an ASF member, right? What were his concerns about
>> the ASF that made him start his project elsewhere?
>
> Ceki is an ASF member and even a Logging PMC.
> You can read most about his concerns on his blog, for example:
> http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html
> http://ceki.blogspot.com/2010/05/committocracy-as-alternative-for.html
>
> He seems to be very opposed to the ASF model; there was much bad
> feelings in the "log4j case" before I started with logging and
> therefore I doubt that Ceki is willing to go back to the ASF. At least
> his blogposts reflect that he is not satisfied with the "Apache Way"
> itself instead of personal trouble, which we might be able to solve.
> Ceki is reading this list, so maybe he wants to elaborate a bit more.
>
> The logback project is not satisfying me as a developer. I am at the
> ASF because I like the way it is. I like the software. And of course I
> like the way the work is done here and finally I like the license.
>
> logback/slf4j is going another way. It does not have the license, and
> holidays seem to be very important to the project.
>
> We, the ASF, have really good software in our repositories. We have
> very competent people around. Why do we discuss to move to
> slf4j/logback - now? The last time we discussed this there was less
> activity on logging. Now there is activity on the logging project at
> apache. There is Ralph and some other people doing lots of work for
> log4j2.
> We have learned there are some people who want commons-logging. We
> have learned in Tomcat are some people who created classloader
> workarounds and know about the case and could help with it.
>
> It feels wrong to me to move away to slf4j/logback with Commons at
> this point of time. We would kill the new growing dynamics of logging.
> Instead we should use the new interest and try to work together on the
> new log4j/commons-logging. Over at logging we welcome new fresh blood.
>
> After all, even log4j 1.2.x is not bad software. I use it daily; i
> have not missed the features of logback (parametrized messages,
> Markers etc.) so far. I put log4j in my class path, copy over one of
> my fave configuration, ready. No need to waste any more time to this.
> log4j is still good and at the moment I don't see a reason to move on.
>
> In the commons-logging case, if the commons-* projects stop using
> commons-logging, then commons-logging feels pretty dead.
>
> So my preference is:
>
> - Help Ralph to make log4j 2.0 become truth
> - Update commons-logging, make it work with log4j 2.0
> - Try to make log4j 2.0 become compatible with slf4j
+1
>
> If one of you is interested in helping with log4j, please subscribe to
> log4j-dev@logging.apache.org
Done.
Nice message Christian.
Gary
>
> Cheers
> Christian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Christian Grobmeier <gr...@gmail.com>.
>> Another option is to try to work with Ceki to address some of the
>> concerns of the commons community with regards to using slf4j.
>>
>> * There is a hassle with too many jars for dependencies with slf4j.
>> * Every time Ceki goes on vacation everything stops.
>> * Some have a preference for Apache driven projects.
>> * Figuring out the dependencies that are needed can be difficult.
>
> Another option would be to try to convince Ceki to move his project to
> the ASF? He is an ASF member, right? What were his concerns about
> the ASF that made him start his project elsewhere?
Ceki is an ASF member and even a Logging PMC.
You can read most about his concerns on his blog, for example:
http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html
http://ceki.blogspot.com/2010/05/committocracy-as-alternative-for.html
He seems to be very opposed to the ASF model; there was much bad
feelings in the "log4j case" before I started with logging and
therefore I doubt that Ceki is willing to go back to the ASF. At least
his blogposts reflect that he is not satisfied with the "Apache Way"
itself instead of personal trouble, which we might be able to solve.
Ceki is reading this list, so maybe he wants to elaborate a bit more.
The logback project is not satisfying me as a developer. I am at the
ASF because I like the way it is. I like the software. And of course I
like the way the work is done here and finally I like the license.
logback/slf4j is going another way. It does not have the license, and
holidays seem to be very important to the project.
We, the ASF, have really good software in our repositories. We have
very competent people around. Why do we discuss to move to
slf4j/logback - now? The last time we discussed this there was less
activity on logging. Now there is activity on the logging project at
apache. There is Ralph and some other people doing lots of work for
log4j2.
We have learned there are some people who want commons-logging. We
have learned in Tomcat are some people who created classloader
workarounds and know about the case and could help with it.
It feels wrong to me to move away to slf4j/logback with Commons at
this point of time. We would kill the new growing dynamics of logging.
Instead we should use the new interest and try to work together on the
new log4j/commons-logging. Over at logging we welcome new fresh blood.
After all, even log4j 1.2.x is not bad software. I use it daily; i
have not missed the features of logback (parametrized messages,
Markers etc.) so far. I put log4j in my class path, copy over one of
my fave configuration, ready. No need to waste any more time to this.
log4j is still good and at the moment I don't see a reason to move on.
In the commons-logging case, if the commons-* projects stop using
commons-logging, then commons-logging feels pretty dead.
So my preference is:
- Help Ralph to make log4j 2.0 become truth
- Update commons-logging, make it work with log4j 2.0
- Try to make log4j 2.0 become compatible with slf4j
If one of you is interested in helping with log4j, please subscribe to
log4j-dev@logging.apache.org
Cheers
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by James Carman <ja...@carmanconsulting.com>.
On Mon, Aug 8, 2011 at 5:58 PM, Elijah Zupancic <el...@zupancic.name> wrote:
>
> Another option is to try to work with Ceki to address some of the
> concerns of the commons community with regards to using slf4j.
>
> * There is a hassle with too many jars for dependencies with slf4j.
> * Every time Ceki goes on vacation everything stops.
> * Some have a preference for Apache driven projects.
> * Figuring out the dependencies that are needed can be difficult.
Another option would be to try to convince Ceki to move his project to
the ASF? He is an ASF member, right? What were his concerns about
the ASF that made him start his project elsewhere?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Elijah Zupancic <el...@zupancic.name>.
Raman,
You may have proposed this earlier in the thread and I didn't catch
it. I actually like your suggestion the best, but it seems like it is
a difficult sell for a lot of people to compile against the slf4j API
for a variety of reasons that are not strictly code related.
My suggestion was intended to bridge the gap between the concerns
toward compiling directly against slf4j.
Another option is to try to work with Ceki to address some of the
concerns of the commons community with regards to using slf4j.
>From what I can tell from the thread, here are the following points
against SLF4J:
* Log4j developer V2 would like to see the Apache community support
the project rather than putting resources into slf4j.
* Slf4j apparently has some deficiencies in its API such as: "SLF4J
has to convert the EventData object to XML since SLF4J/Logback don't
provide a good way of handling this."
* Log4j V2 also implements support for the Slf4j API.
* There is a hassle with too many jars for dependencies with slf4j.
* Every time Ceki goes on vacation everything stops.
* Some have a preference for Apache driven projects.
* Figuring out the dependencies that are needed can be difficult.
If we can come to some consensus regarding this issues, then I think
there will be more traction toward Slf4j.
Thanks,
-Elijah
On Mon, Aug 8, 2011 at 2:13 PM, Raman Gupta <ro...@fastmail.fm> wrote:
> On 08/08/2011 04:56 PM, Elijah Zupancic wrote:
>> This could be done by choosing (dynamically or by configuration) the
>> logger implementation log4j / commons / slf4j / jul and then loading
>> the LoggerFactory into a wrapper class that is then called used by the
>> Commons project.
>>
>> We would then make the logger implementations a compile-time
>> dependency only and relay upon the consumer to provide them.
>>
>> I do realize that this is essentially doing a Facade on top of a
>> Facade, but it solves the problem for consumers of the library by
>> providing many options.
>>
>> So, am I crazy?
>
> If I understand you correctly, you would have this dependency chain:
>
> random-commons-project ->
> commons-logging-wrapper ->
> API like slf4j or logging implementation (at runtime)
>
> Plus commons-logging-wrapper requires compile-time knowledge of all
> possible target frameworks, since it is not coding to an API.
>
> Can you explain the advantage over simply coding
> random-commons-project against slf4j-api.jar? Then, you have this
> dependency chain:
>
> random-commons-project ->
> slf4j-api ->
> logging implementation (at runtime)
>
> And anyone can create their own slf4j compatible logging
> implementation simply by implementing the slf4j api and dropping their
> jar into their environment.
>
> Cheers,
> Raman
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Raman Gupta <ro...@fastmail.fm>.
On 08/08/2011 04:56 PM, Elijah Zupancic wrote:
> This could be done by choosing (dynamically or by configuration) the
> logger implementation log4j / commons / slf4j / jul and then loading
> the LoggerFactory into a wrapper class that is then called used by the
> Commons project.
>
> We would then make the logger implementations a compile-time
> dependency only and relay upon the consumer to provide them.
>
> I do realize that this is essentially doing a Facade on top of a
> Facade, but it solves the problem for consumers of the library by
> providing many options.
>
> So, am I crazy?
If I understand you correctly, you would have this dependency chain:
random-commons-project ->
commons-logging-wrapper ->
API like slf4j or logging implementation (at runtime)
Plus commons-logging-wrapper requires compile-time knowledge of all
possible target frameworks, since it is not coding to an API.
Can you explain the advantage over simply coding
random-commons-project against slf4j-api.jar? Then, you have this
dependency chain:
random-commons-project ->
slf4j-api ->
logging implementation (at runtime)
And anyone can create their own slf4j compatible logging
implementation simply by implementing the slf4j api and dropping their
jar into their environment.
Cheers,
Raman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Elijah Zupancic <el...@gmail.com>.
I agree with this sentiment. In the last 3 years all of the large
commercial projects that I have worked on used slf4j just for the very
reason that I needed to bridge the logging implementations in multiple
third-party libraries.
While reading this thread, one approach occurs to me that hasn't been
mentioned. Why not abstract the abstraction? My gut reaction to this
approach is negative, but I do feel that it is quite pragmatic.
This could be done by choosing (dynamically or by configuration) the
logger implementation log4j / commons / slf4j / jul and then loading
the LoggerFactory into a wrapper class that is then called used by the
Commons project.
We would then make the logger implementations a compile-time
dependency only and relay upon the consumer to provide them.
I do realize that this is essentially doing a Facade on top of a
Facade, but it solves the problem for consumers of the library by
providing many options.
So, am I crazy?
-Elijah
> Yes, the reality is large applications need to support multiple source
> frameworks and will therefore require a bunch of logging jars. Slf4j
> provides a relatively simple path to consolidating logs from jcl, jul,
> and log4j into one's chosen target framework (except for jul).
>
> With the current landscape, you are dreaming if you think one magical
> jar is going to support all use cases. This would have been simple if
> jul had been designed properly, but it wasn't.
>
> Cheers,
> Raman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Raman Gupta <ro...@fastmail.fm>.
On 08/08/2011 03:28 PM, Matt Benson wrote:
> On Mon, Aug 8, 2011 at 2:23 PM, Paul Benedict <pb...@apache.org> wrote:
>> On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta <ro...@fastmail.fm> wrote:
>>> Perhaps I'm missing something, but what exactly is wrong with simply
>>> using slf4j? It is an extremely simple, widely used library that
>>> provides out of the box hooks for many logging frameworks including
>>> log4j and logback, simple to configure (i.e. drop the appropriate jars
>>> in and thats it), and works out of the box in an OSGi environment? The
>>> only downside appears to be that it is not an Apache project. So what.
>>
>> The biggest issue I have with SLF4J is figuring out the dependencies
>> that I need. I really detest having an API jar and then an
>> implementation/bridge jar. I find that too annoying.
This is nothing new -- commons-logging requires the
commons-logging.jar for library creators, and users need
commons-logging.jar plus an implementation jar.
Slf4j requires the same: slf4j-api.jar for library creators and an
implementation jar for users. The bridging jars are *optional* and
only required by users to bridge from jcl, jul, or log4j.
> In fairness, using a dependency manager with support for transitive
> dependencies you should only have to specify the implementation jar.
> In the case of slf4j you may have to provide multiple jars (impl +
> bridge X n logging frameworks in use throughout your application),
> however. Of course, log4j v2 will have to support this paradigm in
> some fashion or lose runtime "market share" due to slf4j's ability to
> cater to the "lowest common denominator."
Yes, the reality is large applications need to support multiple source
frameworks and will therefore require a bunch of logging jars. Slf4j
provides a relatively simple path to consolidating logs from jcl, jul,
and log4j into one's chosen target framework (except for jul).
With the current landscape, you are dreaming if you think one magical
jar is going to support all use cases. This would have been simple if
jul had been designed properly, but it wasn't.
Cheers,
Raman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Matt Benson <gu...@gmail.com>.
On Mon, Aug 8, 2011 at 2:23 PM, Paul Benedict <pb...@apache.org> wrote:
> On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta <ro...@fastmail.fm> wrote:
>> Perhaps I'm missing something, but what exactly is wrong with simply
>> using slf4j? It is an extremely simple, widely used library that
>> provides out of the box hooks for many logging frameworks including
>> log4j and logback, simple to configure (i.e. drop the appropriate jars
>> in and thats it), and works out of the box in an OSGi environment? The
>> only downside appears to be that it is not an Apache project. So what.
>
> The biggest issue I have with SLF4J is figuring out the dependencies
> that I need. I really detest having an API jar and then an
> implementation/bridge jar. I find that too annoying.
>
In fairness, using a dependency manager with support for transitive
dependencies you should only have to specify the implementation jar.
In the case of slf4j you may have to provide multiple jars (impl +
bridge X n logging frameworks in use throughout your application),
however. Of course, log4j v2 will have to support this paradigm in
some fashion or lose runtime "market share" due to slf4j's ability to
cater to the "lowest common denominator."
Matt
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Paul Benedict <pb...@apache.org>.
On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta <ro...@fastmail.fm> wrote:
> Perhaps I'm missing something, but what exactly is wrong with simply
> using slf4j? It is an extremely simple, widely used library that
> provides out of the box hooks for many logging frameworks including
> log4j and logback, simple to configure (i.e. drop the appropriate jars
> in and thats it), and works out of the box in an OSGi environment? The
> only downside appears to be that it is not an Apache project. So what.
The biggest issue I have with SLF4J is figuring out the dependencies
that I need. I really detest having an API jar and then an
implementation/bridge jar. I find that too annoying.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Raman Gupta <ro...@fastmail.fm>.
On 08/08/2011 02:00 PM, ralph.goers @dslextreme.com wrote:
> On Mon, Aug 8, 2011 at 8:06 AM, Simone Tripodi <si...@apache.org>wrote:
>>>> If we really have to reconsider this stuff, then I'd propose to
>>>>
>>>> a) Use java.util.logging, because it doesn't require any additional
>>>> dependencies and is guaranteed to work anywhere.
>>>> b) Carefully document how to bridge jul to log4j, because that's
>>>> exactly what's required in almost any application container I am aware
>>>> of. (The exception being Tomcat, which uses jul anyways.)
>>>> c) If the slf4j fans insist, add similar documentation for bridging
>>>> jul to slf4j.
>>>
>>> +1. I like this plan.
>>>
>>
>> +1 I like this plan too. it sounds *very* reasonable: unified,
>> standard (?) way to log, easy to bridge to everything needed.
>> can we ask more?
>> have a nice day, all the best!!!
>> Simo
>
> I'm not a fan of this plan. Have you actually tried to "bridge" jul to
> anything? While it will work anywhere that doesn't imply it will work
> properly.
>
> Ralph
I'm not a fan of this plan either. Jul bridging is not simple because
JUL doesn't provide the necessary hooks, and packages under the java.*
namespace can't be replaced.
For example, see this slf4j page:
http://www.slf4j.org/legacy.html
To quote one relevant sentence:
"...Consequently, j.u.l. to SLF4J translation can seriously impact on
the cost of disabled logging statements (60 fold increase) and a
measurable impact on enabled log statements (20% overall increase)."
Logging to Logback via slf4j does provide a work-around to the above
performance problem (LevelChangePropagator) but other frameworks may
not (log4j?), and in general configuring the JUL bridge is much harder
than it should be, and many users will get it wrong. Other frameworks
may have similar issues bridging JUL as well.
Perhaps I'm missing something, but what exactly is wrong with simply
using slf4j? It is an extremely simple, widely used library that
provides out of the box hooks for many logging frameworks including
log4j and logback, simple to configure (i.e. drop the appropriate jars
in and thats it), and works out of the box in an OSGi environment? The
only downside appears to be that it is not an Apache project. So what.
Cheers,
Raman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by "ralph.goers @dslextreme.com" <ra...@dslextreme.com>.
I'm not a fan of this plan. Have you actually tried to "bridge" jul to
anything? While it will work anywhere that doesn't imply it will work
properly.
Ralph
On Mon, Aug 8, 2011 at 8:06 AM, Simone Tripodi <si...@apache.org>wrote:
> Hi all,
>
> >>
> >> If we really have to reconsider this stuff, then I'd propose to
> >>
> >> a) Use java.util.logging, because it doesn't require any additional
> >> dependencies and is guaranteed to work anywhere.
> >> b) Carefully document how to bridge jul to log4j, because that's
> >> exactly what's required in almost any application container I am aware
> >> of. (The exception being Tomcat, which uses jul anyways.)
> >> c) If the slf4j fans insist, add similar documentation for bridging
> >> jul to slf4j.
> >
> > +1. I like this plan.
> >
>
> +1 I like this plan too. it sounds *very* reasonable: unified,
> standard (?) way to log, easy to bridge to everything needed.
> can we ask more?
> have a nice day, all the best!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [logging] logging vs slf4j
Posted by Simone Tripodi <si...@apache.org>.
Hi all,
>>
>> If we really have to reconsider this stuff, then I'd propose to
>>
>> a) Use java.util.logging, because it doesn't require any additional
>> dependencies and is guaranteed to work anywhere.
>> b) Carefully document how to bridge jul to log4j, because that's
>> exactly what's required in almost any application container I am aware
>> of. (The exception being Tomcat, which uses jul anyways.)
>> c) If the slf4j fans insist, add similar documentation for bridging
>> jul to slf4j.
>
> +1. I like this plan.
>
+1 I like this plan too. it sounds *very* reasonable: unified,
standard (?) way to log, easy to bridge to everything needed.
can we ask more?
have a nice day, all the best!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/8/7 Mark Thomas <ma...@apache.org>:
> On 07/08/2011 09:31, Jochen Wiedmann wrote:
>> On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory <ga...@gmail.com> wrote:
>>
>>> Or maybe Log4j 2 could replace [logging].
>>
>> If we really have to reconsider this stuff, then I'd propose to
>>
>> a) Use java.util.logging, because it doesn't require any additional
>> dependencies and is guaranteed to work anywhere.
>> b) Carefully document how to bridge jul to log4j, because that's
>> exactly what's required in almost any application container I am aware
>> of. (The exception being Tomcat, which uses jul anyways.)
>> c) If the slf4j fans insist, add similar documentation for bridging
>> jul to slf4j.
>
> +1. I like this plan.
>
> As an aside, Tomcat doesn't use jul, it uses JULI which is a modified
> commons logging implementation hard coded to output to jul by default
> with an alternative Jar that is hard-coded for log4j. Why the
> complexity? jul is not class loader aware which is a problem as soon as
> web applications start declaring loggers with the same name.
>
> Mark
Regarding Tomcat,
I want to correct Mark. Tomcat JULI != commons-logging. It is just
that two components are packed in the same jar. (E.g. in Tomcat 5.5
they were separate).
Tomcat logging (the "bin/tomcat-juli.jar:" file) contains the following:
1. Tomcat JULI which are additional components to java.util.logging.
There are two main components:
a) a custom implementation of java.util.logging.LogManager that is
classloader-aware, allows to have separate logging configuration per
webapp, and also to have more rich configurations than the default
LogManager
b) a custom FileHandler, that is better suited to our needs than the
standard one.
Tomcat JULI is enabled by setting certain java properties on the command line.
2. A copy of commons-logging renamed to a different package to avoid
conflicts with webapp-provided copies of the library.
The "tomcat-juli.jar:" can come in two flavors.
Default one: The default one uses stripped down copy of
commons-logging that has its discovery process removed and is
hardcoded to use java.util.logging.
Extras one: This includes full copy of commons-logging. It is *not*
hard-coded for log4j. It is just that its discovery process is kept
intact, so it can choose whatever logging framework it finds.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Mark Thomas <ma...@apache.org>.
On 07/08/2011 09:31, Jochen Wiedmann wrote:
> On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory <ga...@gmail.com> wrote:
>
>> Or maybe Log4j 2 could replace [logging].
>
> If we really have to reconsider this stuff, then I'd propose to
>
> a) Use java.util.logging, because it doesn't require any additional
> dependencies and is guaranteed to work anywhere.
> b) Carefully document how to bridge jul to log4j, because that's
> exactly what's required in almost any application container I am aware
> of. (The exception being Tomcat, which uses jul anyways.)
> c) If the slf4j fans insist, add similar documentation for bridging
> jul to slf4j.
+1. I like this plan.
As an aside, Tomcat doesn't use jul, it uses JULI which is a modified
commons logging implementation hard coded to output to jul by default
with an alternative Jar that is hard-coded for log4j. Why the
complexity? jul is not class loader aware which is a problem as soon as
web applications start declaring loggers with the same name.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory <ga...@gmail.com> wrote:
> Or maybe Log4j 2 could replace [logging].
If we really have to reconsider this stuff, then I'd propose to
a) Use java.util.logging, because it doesn't require any additional
dependencies and is guaranteed to work anywhere.
b) Carefully document how to bridge jul to log4j, because that's
exactly what's required in almost any application container I am aware
of. (The exception being Tomcat, which uses jul anyways.)
c) If the slf4j fans insist, add similar documentation for bridging
jul to slf4j.
Jochen
--
Capitalism is the astounding belief that the most wickedest of men
will do the most wickedest of things for the greatest good of
everyone.
John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [logging] logging vs slf4j
Posted by Simone Tripodi <si...@apache.org>.
Well said Hen, big +1 :)
>
> B) If you are an app, use log4j.
or logback, depending on the cases, IMHO
>
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Aug 5, 2011 at 8:18 AM, Henri Yandell <fl...@gmail.com> wrote:
> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory <ga...@gmail.com> wrote:
>> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict <pb...@apache.org> wrote:
>>> I prefer Apache driven projects when possible. If LOG4J2 takes off,
>>> feature requests would be implemented quicker, I hope.
>>
>> I like Log4J just fine thank you very much :)
>>
>> I'm looking forward to 2.0.
>
> That's generally where I am thought-wise.
>
> A) If you're a generic reusble library; don't do logging if you can help it.
> B) If you are an app, use log4j.
> C) If you truly need a bridge, use SLF4j.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Henri Yandell <fl...@gmail.com>.
On Fri, Aug 5, 2011 at 4:07 PM, Gary Gregory <ga...@gmail.com> wrote:
> On Aug 5, 2011, at 16:27, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 8/5/11 12:53 PM, Henri Yandell wrote:
>>> HttpComponents would be SFL4j in my structure. They definitely need debugging.
>>>
>>> Lang or Codec don't.
>>>
>>> If I had to generalize, I'd say it's because HttpComponents is not at
>>> the bottom of its stack. You need to know what the communication is
>>> between HttpComponents and the API below it (ie) a http connection to
>>> a server).
>>>
>>> Digester and DBCP are two other areas in which logging is very
>>> attractive (how is it talking to the XML or a DB).
>>>
>>> Pool less so imo - what you really want is status information on the
>>> state of the pool. Ideally we're talking event-based systems and
>>> querying rather than just simple logging [not that I've looked at Pool
>>> in eons].
>>
>> I see [pool] and [dbcp] as having similar needs. Could be good JMX
>> instrumentation can do it all. Needs from the client perspective
>> are to be able to query the state of the pool and be notified or
>> provide a log of events of interest. In the case of [pool], most
>> events of interest involve the factory, so the workaround up to now
>> has been to add needed capabilities to the factory.
>>
>> I don't get why we should abandon [logging] in favor of a non-ASF,
>> BDFL-esque thingy if [logging] works as a bridge.
>
> +1
Looking forward to Logging 1.1.2 being released :)
Hen
[Grim Reaper, Janitor, Mr Attic etc etc]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Gary Gregory <ga...@gmail.com>.
On Aug 5, 2011, at 16:27, Phil Steitz <ph...@gmail.com> wrote:
> On 8/5/11 12:53 PM, Henri Yandell wrote:
>> HttpComponents would be SFL4j in my structure. They definitely need debugging.
>>
>> Lang or Codec don't.
>>
>> If I had to generalize, I'd say it's because HttpComponents is not at
>> the bottom of its stack. You need to know what the communication is
>> between HttpComponents and the API below it (ie) a http connection to
>> a server).
>>
>> Digester and DBCP are two other areas in which logging is very
>> attractive (how is it talking to the XML or a DB).
>>
>> Pool less so imo - what you really want is status information on the
>> state of the pool. Ideally we're talking event-based systems and
>> querying rather than just simple logging [not that I've looked at Pool
>> in eons].
>
> I see [pool] and [dbcp] as having similar needs. Could be good JMX
> instrumentation can do it all. Needs from the client perspective
> are to be able to query the state of the pool and be notified or
> provide a log of events of interest. In the case of [pool], most
> events of interest involve the factory, so the workaround up to now
> has been to add needed capabilities to the factory.
>
> I don't get why we should abandon [logging] in favor of a non-ASF,
> BDFL-esque thingy if [logging] works as a bridge.
+1
Gary
> What I am not
> sure about for [pool] and [dbcp] is if JMX instrumentation and some
> other API improvements might just meet the need without introducing
> logging at all.
>
> I think we are conflating two different topics on this thread - 1)
> future of [logging] 2) what commons components should use for
> logging. Unless [logging] has terrible flaws that somehow fixed in
> the SF thing, we should use it, IMO.
>
> Phil
>>
>> It's a set of decisions you have to make - what I'm advocating (with
>> 'if you can help it') is to ask yourself "do I need logging?" rather
>> than "how can I add logging?". I think a lot is added due to the
>> latter approach.
>>
>> Hen
>>
>> On Fri, Aug 5, 2011 at 5:23 AM, Bill Speirs <bi...@gmail.com> wrote:
>>> IMO, saying "Don't do logging in a library" seems like a bad rule.
>>>
>>> The HTTPComponents client has logging and it has been VERY helpful to be
>>> able to turn on debug logging and see what requests and responses are going
>>> over the wire. Yes, I could fire up Wireshark and get the same info, but
>>> turning on logging is so much easier... I only wish they had this for the
>>> HttpCore stuff.
>>>
>>> Why do you suggest no logging for libraries?
>>>
>>> Bill-
>>>
>>> On Aug 5, 2011 2:19 AM, "Henri Yandell" <fl...@gmail.com> wrote:
>>>> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>>> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict <pb...@apache.org>
>>> wrote:
>>>>>> I prefer Apache driven projects when possible. If LOG4J2 takes off,
>>>>>> feature requests would be implemented quicker, I hope.
>>>>> I like Log4J just fine thank you very much :)
>>>>>
>>>>> I'm looking forward to 2.0.
>>>> That's generally where I am thought-wise.
>>>>
>>>> A) If you're a generic reusble library; don't do logging if you can help
>>> it.
>>>> B) If you are an app, use log4j.
>>>> C) If you truly need a bridge, use SLF4j.
>>>>
>>>> Hen
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Phil Steitz <ph...@gmail.com>.
On 8/5/11 12:53 PM, Henri Yandell wrote:
> HttpComponents would be SFL4j in my structure. They definitely need debugging.
>
> Lang or Codec don't.
>
> If I had to generalize, I'd say it's because HttpComponents is not at
> the bottom of its stack. You need to know what the communication is
> between HttpComponents and the API below it (ie) a http connection to
> a server).
>
> Digester and DBCP are two other areas in which logging is very
> attractive (how is it talking to the XML or a DB).
>
> Pool less so imo - what you really want is status information on the
> state of the pool. Ideally we're talking event-based systems and
> querying rather than just simple logging [not that I've looked at Pool
> in eons].
I see [pool] and [dbcp] as having similar needs. Could be good JMX
instrumentation can do it all. Needs from the client perspective
are to be able to query the state of the pool and be notified or
provide a log of events of interest. In the case of [pool], most
events of interest involve the factory, so the workaround up to now
has been to add needed capabilities to the factory.
I don't get why we should abandon [logging] in favor of a non-ASF,
BDFL-esque thingy if [logging] works as a bridge. What I am not
sure about for [pool] and [dbcp] is if JMX instrumentation and some
other API improvements might just meet the need without introducing
logging at all.
I think we are conflating two different topics on this thread - 1)
future of [logging] 2) what commons components should use for
logging. Unless [logging] has terrible flaws that somehow fixed in
the SF thing, we should use it, IMO.
Phil
>
> It's a set of decisions you have to make - what I'm advocating (with
> 'if you can help it') is to ask yourself "do I need logging?" rather
> than "how can I add logging?". I think a lot is added due to the
> latter approach.
>
> Hen
>
> On Fri, Aug 5, 2011 at 5:23 AM, Bill Speirs <bi...@gmail.com> wrote:
>> IMO, saying "Don't do logging in a library" seems like a bad rule.
>>
>> The HTTPComponents client has logging and it has been VERY helpful to be
>> able to turn on debug logging and see what requests and responses are going
>> over the wire. Yes, I could fire up Wireshark and get the same info, but
>> turning on logging is so much easier... I only wish they had this for the
>> HttpCore stuff.
>>
>> Why do you suggest no logging for libraries?
>>
>> Bill-
>>
>> On Aug 5, 2011 2:19 AM, "Henri Yandell" <fl...@gmail.com> wrote:
>>> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict <pb...@apache.org>
>> wrote:
>>>>> I prefer Apache driven projects when possible. If LOG4J2 takes off,
>>>>> feature requests would be implemented quicker, I hope.
>>>> I like Log4J just fine thank you very much :)
>>>>
>>>> I'm looking forward to 2.0.
>>> That's generally where I am thought-wise.
>>>
>>> A) If you're a generic reusble library; don't do logging if you can help
>> it.
>>> B) If you are an app, use log4j.
>>> C) If you truly need a bridge, use SLF4j.
>>>
>>> Hen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Ceki Gülcü <ce...@qos.ch>.
On 05/08/2011 9:53 PM, Henri Yandell wrote:
>
> It's a set of decisions you have to make - what I'm advocating (with
> 'if you can help it') is to ask yourself "do I need logging?" rather
> than "how can I add logging?". I think a lot is added due to the
> latter approach.
+1
> Hen
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Henri Yandell <fl...@gmail.com>.
HttpComponents would be SFL4j in my structure. They definitely need debugging.
Lang or Codec don't.
If I had to generalize, I'd say it's because HttpComponents is not at
the bottom of its stack. You need to know what the communication is
between HttpComponents and the API below it (ie) a http connection to
a server).
Digester and DBCP are two other areas in which logging is very
attractive (how is it talking to the XML or a DB).
Pool less so imo - what you really want is status information on the
state of the pool. Ideally we're talking event-based systems and
querying rather than just simple logging [not that I've looked at Pool
in eons].
It's a set of decisions you have to make - what I'm advocating (with
'if you can help it') is to ask yourself "do I need logging?" rather
than "how can I add logging?". I think a lot is added due to the
latter approach.
Hen
On Fri, Aug 5, 2011 at 5:23 AM, Bill Speirs <bi...@gmail.com> wrote:
> IMO, saying "Don't do logging in a library" seems like a bad rule.
>
> The HTTPComponents client has logging and it has been VERY helpful to be
> able to turn on debug logging and see what requests and responses are going
> over the wire. Yes, I could fire up Wireshark and get the same info, but
> turning on logging is so much easier... I only wish they had this for the
> HttpCore stuff.
>
> Why do you suggest no logging for libraries?
>
> Bill-
>
> On Aug 5, 2011 2:19 AM, "Henri Yandell" <fl...@gmail.com> wrote:
>> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory <ga...@gmail.com>
> wrote:
>>> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict <pb...@apache.org>
> wrote:
>>>> I prefer Apache driven projects when possible. If LOG4J2 takes off,
>>>> feature requests would be implemented quicker, I hope.
>>>
>>> I like Log4J just fine thank you very much :)
>>>
>>> I'm looking forward to 2.0.
>>
>> That's generally where I am thought-wise.
>>
>> A) If you're a generic reusble library; don't do logging if you can help
> it.
>> B) If you are an app, use log4j.
>> C) If you truly need a bridge, use SLF4j.
>>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Aug 5, 2011 at 8:59 AM, Gary Gregory <ga...@gmail.com> wrote:
> On Fri, Aug 5, 2011 at 8:23 AM, Bill Speirs <bi...@gmail.com> wrote:
>> IMO, saying "Don't do logging in a library" seems like a bad rule.
>>
>> The HTTPComponents client has logging and it has been VERY helpful to be
>> able to turn on debug logging and see what requests and responses are going
>> over the wire. Yes, I could fire up Wireshark and get the same info, but
>> turning on logging is so much easier... I only wish they had this for the
>> HttpCore stuff.
>>
>> Why do you suggest no logging for libraries?
>
> Yes, IMO the question should be: How and when do you do logging in a library?
>
> - if () System.out...
> - // System.out...
> - A logging lib
> - ...
For example, in [codec] trunk, the new BM encoder uses "// System.out"
(yuck), which then causes PMD warnings because some blocks are empty.
Gary
>
> Gary
>
>>
>> Bill-
>>
>> On Aug 5, 2011 2:19 AM, "Henri Yandell" <fl...@gmail.com> wrote:
>>> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict <pb...@apache.org>
>> wrote:
>>>>> I prefer Apache driven projects when possible. If LOG4J2 takes off,
>>>>> feature requests would be implemented quicker, I hope.
>>>>
>>>> I like Log4J just fine thank you very much :)
>>>>
>>>> I'm looking forward to 2.0.
>>>
>>> That's generally where I am thought-wise.
>>>
>>> A) If you're a generic reusble library; don't do logging if you can help
>> it.
>>> B) If you are an app, use log4j.
>>> C) If you truly need a bridge, use SLF4j.
>>>
>>> Hen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Aug 5, 2011 at 8:23 AM, Bill Speirs <bi...@gmail.com> wrote:
> IMO, saying "Don't do logging in a library" seems like a bad rule.
>
> The HTTPComponents client has logging and it has been VERY helpful to be
> able to turn on debug logging and see what requests and responses are going
> over the wire. Yes, I could fire up Wireshark and get the same info, but
> turning on logging is so much easier... I only wish they had this for the
> HttpCore stuff.
>
> Why do you suggest no logging for libraries?
Yes, IMO the question should be: How and when do you do logging in a library?
- if () System.out...
- // System.out...
- A logging lib
- ...
Gary
>
> Bill-
>
> On Aug 5, 2011 2:19 AM, "Henri Yandell" <fl...@gmail.com> wrote:
>> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory <ga...@gmail.com>
> wrote:
>>> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict <pb...@apache.org>
> wrote:
>>>> I prefer Apache driven projects when possible. If LOG4J2 takes off,
>>>> feature requests would be implemented quicker, I hope.
>>>
>>> I like Log4J just fine thank you very much :)
>>>
>>> I'm looking forward to 2.0.
>>
>> That's generally where I am thought-wise.
>>
>> A) If you're a generic reusble library; don't do logging if you can help
> it.
>> B) If you are an app, use log4j.
>> C) If you truly need a bridge, use SLF4j.
>>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Bill Speirs <bi...@gmail.com>.
IMO, saying "Don't do logging in a library" seems like a bad rule.
The HTTPComponents client has logging and it has been VERY helpful to be
able to turn on debug logging and see what requests and responses are going
over the wire. Yes, I could fire up Wireshark and get the same info, but
turning on logging is so much easier... I only wish they had this for the
HttpCore stuff.
Why do you suggest no logging for libraries?
Bill-
On Aug 5, 2011 2:19 AM, "Henri Yandell" <fl...@gmail.com> wrote:
> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory <ga...@gmail.com>
wrote:
>> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict <pb...@apache.org>
wrote:
>>> I prefer Apache driven projects when possible. If LOG4J2 takes off,
>>> feature requests would be implemented quicker, I hope.
>>
>> I like Log4J just fine thank you very much :)
>>
>> I'm looking forward to 2.0.
>
> That's generally where I am thought-wise.
>
> A) If you're a generic reusble library; don't do logging if you can help
it.
> B) If you are an app, use log4j.
> C) If you truly need a bridge, use SLF4j.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [logging] logging vs slf4j
Posted by Henri Yandell <fl...@gmail.com>.
On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory <ga...@gmail.com> wrote:
> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict <pb...@apache.org> wrote:
>> I prefer Apache driven projects when possible. If LOG4J2 takes off,
>> feature requests would be implemented quicker, I hope.
>
> I like Log4J just fine thank you very much :)
>
> I'm looking forward to 2.0.
That's generally where I am thought-wise.
A) If you're a generic reusble library; don't do logging if you can help it.
B) If you are an app, use log4j.
C) If you truly need a bridge, use SLF4j.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Christian Grobmeier <gr...@gmail.com>.
Paul,
> BTW, in terms of swelling community development, if LOG4J+JCL were to
> merge and just become JCL2, it could have the visibility of all
> Commons committers. Isn't it much more of a common component than a
> separate project? I think the logging project is dysfunctional anyway
> -- make it a common component if possible.
in logging.apache.org are other sub projects doing similar stuff, like
log4php, log4c and such. In addition there is the companions
subproject.
And there is some activity in the logging project. We have had a new
addition to the PMC recently and log4php has released a new version
before a short while. Together with the log4j2 efforts and the efforts
put from time to time into cmpanions and chainsaw, I would say the
project is a bit silent, but not dead.
If you take out log4j, everything else in logging would become instable.
>
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://www.grobmeier.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Paul Benedict <pb...@apache.org>.
On Wed, Aug 3, 2011 at 9:51 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> I like Log4J just fine thank you very much :)
>
> I'm looking forward to 2.0.
>
> Gary
>
I concur with Gary. All my apps use LOG4J, not JCL or SLF4J. My
dependencies do, however, but LOG4J works great minus a few
enhancements I'd like to see.
BTW, in terms of swelling community development, if LOG4J+JCL were to
merge and just become JCL2, it could have the visibility of all
Commons committers. Isn't it much more of a common component than a
separate project? I think the logging project is dysfunctional anyway
-- make it a common component if possible.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict <pb...@apache.org> wrote:
> I prefer Apache driven projects when possible. If LOG4J2 takes off,
> feature requests would be implemented quicker, I hope.
I like Log4J just fine thank you very much :)
I'm looking forward to 2.0.
Gary
>
> On Wed, Aug 3, 2011 at 9:27 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> On Aug 3, 2011, at 6:07 AM, David Karlsen wrote:
>>
>>> Hasn't the time for both CL and log4j passed by? The trend nowadays seems to
>>> be slf4j/logback.
>>
>> If you read further back in this thread you will see where I highlighted the problems in Logback as well as difficulties with SLF4J. Plus, every time Ceki goes on vacation everything stops.
>>
>> Ralph
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Paul Benedict <pb...@apache.org>.
I prefer Apache driven projects when possible. If LOG4J2 takes off,
feature requests would be implemented quicker, I hope.
On Wed, Aug 3, 2011 at 9:27 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> On Aug 3, 2011, at 6:07 AM, David Karlsen wrote:
>
>> Hasn't the time for both CL and log4j passed by? The trend nowadays seems to
>> be slf4j/logback.
>
> If you read further back in this thread you will see where I highlighted the problems in Logback as well as difficulties with SLF4J. Plus, every time Ceki goes on vacation everything stops.
>
> Ralph
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
On Aug 3, 2011, at 6:07 AM, David Karlsen wrote:
> Hasn't the time for both CL and log4j passed by? The trend nowadays seems to
> be slf4j/logback.
If you read further back in this thread you will see where I highlighted the problems in Logback as well as difficulties with SLF4J. Plus, every time Ceki goes on vacation everything stops.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by David Karlsen <da...@gmail.com>.
Hasn't the time for both CL and log4j passed by? The trend nowadays seems to
be slf4j/logback.
Den 3. aug. 2011 15:03 skrev "Gary Gregory" <ga...@gmail.com>
følgende:
> Or maybe Log4j 2 could replace [logging].
>
> Gary
>
> On Wed, Aug 3, 2011 at 5:33 AM, Stephen Colebourne <sc...@joda.org>
wrote:
>> My thought is that there might be some java.util.logging helpers that
>> could be written, and perhaps they might go in [lang] if there are 5
>> or fewer classes.
>>
>> I assume that slf4j and log4j have their own j.u.logging connections,
>> so that end is dealt with.
>>
>> The time of [logging] has probably passed.
>>
>> Stephen
>>
>>
>> On 3 August 2011 06:50, Henri Yandell <fl...@gmail.com> wrote:
>>> On Tue, Aug 2, 2011 at 1:59 AM, Emmanuel Bourg <eb...@apache.org>
wrote:
>>>> Le 28/07/2011 22:01, Henri Yandell a écrit :
>>>>>
>>>>> Personally I'm happy for commons-logging to die. :)
>>>>
>>>> Yeah let's use java.util.logging instead :)
>>>
>>> Primarily that I don't get the feeling we have a major community of
>>> developers on c-logging. We implemented it because we needed something
>>> for our other components (though many simply chose not to log), but it
>>> was never the passion of anybody here (hopefully not an incorrect
>>> statement). Robert, Simon and others put in tons of good work, but I
>>> feel that was duty not passion.
>>>
>>> So happy to see it die because it's something that's headed to
>>> dormancy (be it stable or not).
>>>
>>> Hen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [logging] logging vs slf4j
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory <ga...@gmail.com> wrote:
> Or maybe Log4j 2 could replace [logging].
If we really have to reconsider this stuff, then I'd propose to
a) Use java.util.logging, because it doesn't require any additional
dependencies and is guaranteed to work anywhere.
b) Carefully document how to bridge jul to log4j, because that's
exactly what's required in almost any application container I am aware
of. (The exception being Tomcat, which uses jul anyways.)
c) If the slf4j fans insist, add similar documentation for bridging
jul to slf4j.
Jochen
--
Capitalism is the astounding belief that the most wickedest of men
will do the most wickedest of things for the greatest good of
everyone.
John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Gary Gregory <ga...@gmail.com>.
Or maybe Log4j 2 could replace [logging].
Gary
On Wed, Aug 3, 2011 at 5:33 AM, Stephen Colebourne <sc...@joda.org> wrote:
> My thought is that there might be some java.util.logging helpers that
> could be written, and perhaps they might go in [lang] if there are 5
> or fewer classes.
>
> I assume that slf4j and log4j have their own j.u.logging connections,
> so that end is dealt with.
>
> The time of [logging] has probably passed.
>
> Stephen
>
>
> On 3 August 2011 06:50, Henri Yandell <fl...@gmail.com> wrote:
>> On Tue, Aug 2, 2011 at 1:59 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>> Le 28/07/2011 22:01, Henri Yandell a écrit :
>>>>
>>>> Personally I'm happy for commons-logging to die. :)
>>>
>>> Yeah let's use java.util.logging instead :)
>>
>> Primarily that I don't get the feeling we have a major community of
>> developers on c-logging. We implemented it because we needed something
>> for our other components (though many simply chose not to log), but it
>> was never the passion of anybody here (hopefully not an incorrect
>> statement). Robert, Simon and others put in tons of good work, but I
>> feel that was duty not passion.
>>
>> So happy to see it die because it's something that's headed to
>> dormancy (be it stable or not).
>>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Stephen Colebourne <sc...@joda.org>.
My thought is that there might be some java.util.logging helpers that
could be written, and perhaps they might go in [lang] if there are 5
or fewer classes.
I assume that slf4j and log4j have their own j.u.logging connections,
so that end is dealt with.
The time of [logging] has probably passed.
Stephen
On 3 August 2011 06:50, Henri Yandell <fl...@gmail.com> wrote:
> On Tue, Aug 2, 2011 at 1:59 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>> Le 28/07/2011 22:01, Henri Yandell a écrit :
>>>
>>> Personally I'm happy for commons-logging to die. :)
>>
>> Yeah let's use java.util.logging instead :)
>
> Primarily that I don't get the feeling we have a major community of
> developers on c-logging. We implemented it because we needed something
> for our other components (though many simply chose not to log), but it
> was never the passion of anybody here (hopefully not an incorrect
> statement). Robert, Simon and others put in tons of good work, but I
> feel that was duty not passion.
>
> So happy to see it die because it's something that's headed to
> dormancy (be it stable or not).
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Henri Yandell <fl...@gmail.com>.
On Tue, Aug 2, 2011 at 1:59 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 28/07/2011 22:01, Henri Yandell a écrit :
>>
>> Personally I'm happy for commons-logging to die. :)
>
> Yeah let's use java.util.logging instead :)
Primarily that I don't get the feeling we have a major community of
developers on c-logging. We implemented it because we needed something
for our other components (though many simply chose not to log), but it
was never the passion of anybody here (hopefully not an incorrect
statement). Robert, Simon and others put in tons of good work, but I
feel that was duty not passion.
So happy to see it die because it's something that's headed to
dormancy (be it stable or not).
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 28/07/2011 22:01, Henri Yandell a écrit :
> Personally I'm happy for commons-logging to die. :)
Yeah let's use java.util.logging instead :)
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Henri Yandell <fl...@gmail.com>.
Personally I'm happy for commons-logging to die. :)
On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi
<si...@apache.org> wrote:
> Hi all guys,
> I remember I raw a thread - not sure if I did it here at commons or
> somewhere else here at apache - where specified we prefer adding
> [logging] as components dependency instead of slf4j...
> Did I just get crazy or someone can point me to the right direction please? :)
> Many thanks in advance, all the best!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Antonio Petrelli <an...@gmail.com>.
2011/8/4 Ralph Goers <ra...@dslextreme.com>
> The flaw would be in JBoss Portal, not the portlet spec. The spec doesn't
> have anything to do with logging.
>
In fact I would have said "a library in general" that is referenced both in
the portal application and in portlets.
Anyway you're right, if JBPortal would have shaded the logging framework,
the problem would disappear.
Antonio
Re: [logging] logging vs slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
The flaw would be in JBoss Portal, not the portlet spec. The spec doesn't have anything to do with logging.
Ralph
On Aug 3, 2011, at 11:18 AM, Antonio Petrelli wrote:
> 2011/8/3 Antonio Petrelli <an...@gmail.com>
>
>> However in my experience SLF4J has a big drawback: when used in a shared
>> classloader (JBoss Portal anyone?) it is needed to have the same stinky old
>> version of SLF4J in all applications during compile time, and the library
>> should be excluded from the package.
>>
>
> Correcting myself, this is a flaw in JBoss Portal and/or the portlet
> specification, because they need a shared classloader to work, the same
> problem would happen using commons-logging.
>
> Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Antonio Petrelli <an...@gmail.com>.
2011/8/3 Antonio Petrelli <an...@gmail.com>
> However in my experience SLF4J has a big drawback: when used in a shared
> classloader (JBoss Portal anyone?) it is needed to have the same stinky old
> version of SLF4J in all applications during compile time, and the library
> should be excluded from the package.
>
Correcting myself, this is a flaw in JBoss Portal and/or the portlet
specification, because they need a shared classloader to work, the same
problem would happen using commons-logging.
Antonio
Re: [logging] logging vs slf4j
Posted by Antonio Petrelli <an...@gmail.com>.
First of all, sorry to jump in at this point of the discussion.
2011/7/28 Simone Tripodi <si...@apache.org>
> Hi all guys,
> I remember I raw a thread - not sure if I did it here at commons or
> somewhere else here at apache - where specified we prefer adding
> [logging] as components dependency instead of slf4j...
> Did I just get crazy or someone can point me to the right direction please?
> :)
>
I think that we should start from the fact that many application developers
use Log4j 1.2 for their purposes, simply because it is *enough* configurable
and *enough* useful.
Sincerely I think that we don't need anything more than what Log4j 1.2
already provides.
And I don't think that j.u.logging is useful enough, the configuration is
simply not there.
Stated this, obviously it is out of the question to adopt Log4j, simply
because Commons is made of libraries, and other libraries use other logging
frameworks. So we need a wrapper.
I would choose SLF4J for a simple consideration: there is a Commons Logging
substitute in SLF4J (jcl-over-slf4j) but not a SLF4J substitute in Commons
Logging.
>From a Maven perspective, If Commons Logging is chosen, when a common
library is included, SLF4J users must exclude commons-logging dependency to
add jcl-over-slf4j, for all libraries.
However in my experience SLF4J has a big drawback: when used in a shared
classloader (JBoss Portal anyone?) it is needed to have the same stinky old
version of SLF4J in all applications during compile time, and the library
should be excluded from the package.
Antonio
P.S. The world was better when there was only Log4j :-D
Re: [logging] logging vs slf4j
Posted by Simone Tripodi <si...@apache.org>.
Hi Phil,
I'll have a look at it, of course, at least before any patch will be applied.
Thanks for the reminder, have a nice day!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Thu, Jul 28, 2011 at 10:17 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 7/28/11 1:08 PM, Christian Grobmeier wrote:
>> Hi
>>
>> guess you were looking for this discussion:
>> http://bit.ly/qWAmvZ
>>
>> (you need to read the follow up mails)
>
> Not too obviously to avoid re-opening this discussion - you should
> take a careful look at whether or not [chain] needs to do logging at
> all.
>
> Phil
>>
>> Cheers,
>> Christian
>>
>> On Thu, Jul 28, 2011 at 9:19 PM, Simone Tripodi
>> <si...@apache.org> wrote:
>>> Hi all guys,
>>> I remember I raw a thread - not sure if I did it here at commons or
>>> somewhere else here at apache - where specified we prefer adding
>>> [logging] as components dependency instead of slf4j...
>>> Did I just get crazy or someone can point me to the right direction please? :)
>>> Many thanks in advance, all the best!!!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Phil Steitz <ph...@gmail.com>.
On 7/28/11 1:08 PM, Christian Grobmeier wrote:
> Hi
>
> guess you were looking for this discussion:
> http://bit.ly/qWAmvZ
>
> (you need to read the follow up mails)
Not too obviously to avoid re-opening this discussion - you should
take a careful look at whether or not [chain] needs to do logging at
all.
Phil
>
> Cheers,
> Christian
>
> On Thu, Jul 28, 2011 at 9:19 PM, Simone Tripodi
> <si...@apache.org> wrote:
>> Hi all guys,
>> I remember I raw a thread - not sure if I did it here at commons or
>> somewhere else here at apache - where specified we prefer adding
>> [logging] as components dependency instead of slf4j...
>> Did I just get crazy or someone can point me to the right direction please? :)
>> Many thanks in advance, all the best!!!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Simone Tripodi <si...@apache.org>.
Thanks Christian,
at least the proof I am not crazy!!! :D
Dankeshen!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Thu, Jul 28, 2011 at 10:08 PM, Christian Grobmeier
<gr...@gmail.com> wrote:
> Hi
>
> guess you were looking for this discussion:
> http://bit.ly/qWAmvZ
>
> (you need to read the follow up mails)
>
> Cheers,
> Christian
>
> On Thu, Jul 28, 2011 at 9:19 PM, Simone Tripodi
> <si...@apache.org> wrote:
>> Hi all guys,
>> I remember I raw a thread - not sure if I did it here at commons or
>> somewhere else here at apache - where specified we prefer adding
>> [logging] as components dependency instead of slf4j...
>> Did I just get crazy or someone can point me to the right direction please? :)
>> Many thanks in advance, all the best!!!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> --
> http://www.grobmeier.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] logging vs slf4j
Posted by Christian Grobmeier <gr...@gmail.com>.
Hi
guess you were looking for this discussion:
http://bit.ly/qWAmvZ
(you need to read the follow up mails)
Cheers,
Christian
On Thu, Jul 28, 2011 at 9:19 PM, Simone Tripodi
<si...@apache.org> wrote:
> Hi all guys,
> I remember I raw a thread - not sure if I did it here at commons or
> somewhere else here at apache - where specified we prefer adding
> [logging] as components dependency instead of slf4j...
> Did I just get crazy or someone can point me to the right direction please? :)
> Many thanks in advance, all the best!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://www.grobmeier.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org