Another option would be to use new log4j 2
I still think this one should be handled some day.
Regards
Philippe
On Wednesday, May 8, 2013, Philippe Mouawad wrote:
> Hello,
> I bump this one as since a while we have slf4j as a dependency.
>
> Regards
> Philippe
>
> On Mon, Jan 21, 2013 at 11:01 PM, sebb <seb...@gmail.com<javascript:_e({},
> 'cvml', 'seb...@gmail.com');>
> > wrote:
>
>> On 22 August 2012 23:44, Philippe Mouawad
>> <philippe.moua...@gmail.com<javascript:_e({}, 'cvml',
>> 'philippe.moua...@gmail.com');>>
>> wrote:
>> > Last try to convince you :-)
>> >
>> > On Thursday, August 23, 2012, sebb wrote:
>> >
>> >> On 22 August 2012 21:43, Philippe Mouawad
>> >> <philippe.moua...@gmail.com<javascript:_e({}, 'cvml',
>> >> 'philippe.moua...@gmail.com');>
>> <javascript:;>>
>> >> wrote:
>> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb
>> >> > <seb...@gmail.com<javascript:_e({}, 'cvml',
>> >> > 'seb...@gmail.com');><javascript:;>>
>> >> wrote:
>> >> >
>> >> >> On 22 August 2012 17:52, Milamber
>> >> >> <milam...@apache.org<javascript:_e({}, 'cvml',
>> >> >> 'milam...@apache.org');><javascript:;>>
>> >> wrote:
>> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
>> >> >> > philippe.moua...@gmail.com <javascript:_e({}, 'cvml',
>> 'philippe.moua...@gmail.com');> <javascript:;>> wrote:
>> >> >> >
>> >> >> >> Restarting the discussion about logger.
>> >> >> >>
>> >> >> >> I agree with sebb java.util.logging is not great compared to
>> >> >> slf4j/logback
>> >> >> >> , log4j or commons-logging.
>> >> >> >>
>> >> >> >> My opinion is slf4j/logback would be the best choice as it's:
>> >> >> >>
>> >> >> >> - the most up to date
>> >> >> >> - is the next evolution of LOG4J for logback
>> >> >> >> - was build from commons-logging experience for SLF4J
>> >> >> >> - logback seems to have more features than log4j
>> >> >> >>
>> >> >>
>> >> >> I don't see the point of replacing the existing logging.
>> >> >> What benefit would we get?
>> >> >>
>> >> > Does current implementation support MDC or NDC ?
>> >>
>> >> No idea what they are.
>> >>
>> >>
>> >
>> >
>> >
>> http://veerasundar.com/blog/2009/11/log4j-mdc-mapped-diagnostic-context-example-code/
>>
>> I see, basically a map of variables that can be added to log messages.
>>
>> > http://stackoverflow.com/search?q=%5Blog4j%5D+%2BMDC
>> >
>> >
>> > Milamber wrote an article but it's in french.
>> >
>> >> > Oth
>> >
>> > er features I see:
>> >> >
>> >> > - Parameterized log messages :
>> >> > http://slf4j.org/faq.html#logging_performance
>> >>
>> >> We already use the if enabled wrappers.
>> >>
>> >> More powerful as not String concat and cleaner logging
>> >
>> >> - Marker objects : see
>> >> > -
>> >> >
>> >>
>> http://stackoverflow.com/questions/10766411/overriding-the-logging-methods-logger-warn-in-slf4j
>> >> ,
>> >> >
>> >> > - http://logback.qos.ch/manual/layouts.html#Evaluators
>> >>
>> >> Do we really need this functionality?
>> >> Looks rather complicated to me.
>> >>
>> >> It could be helpful for debugging thread related issues
>> >
>> >>
>> >> >
>> >> > What's wrong with the existing functionality?
>> >> >>
>> >> > it is based on a retired project (Excalibur). It kind of hurts me.
>> >>
>> >> Irrelevant if it works.
>> >
>>
> Yes but don't you think it is a bad thing to have libraries in End Of Life
> ?
> It like using JDK1.4 no ?
>
>> >
>> > I disagree. For dev committers and contributors it's important to have
>> Up
>> > to date and documented APi with lots of resources ( stackoverflow)
>>
>> There are plenty of examples of the use of logging in the code.
>> Anyone who glances at more than a few classes will see how logging is
>> used.
>>
>> > For new comers, they will look at what Libraries are used, too old ones
>> car
>> > fear or can be a negative point.
>>
>> I don't agree.
>> Equally if a brand-new library is used, how well has it been tested?
>>
>> Yes but log4j, logback are hugely tested
>
>> > Furthermore are we sure performances of theseew libraries are not
>> better ?
>> > ( you will kill this argument ;) )
>>
>> Are we sure they are not worse? Especially if they support a lot of
>> special features.
>>
>> Yes
>
>
>> But regardless, the effect on a test run is what counts.
>>
>> >
>> >> > Not much documentation on web, I had to search last time when
>> >> implementing
>> >> > 41788 and 53261. API is limited compared to Commons-logging, log4j ,
>> >> slf4j
>> >>
>> >> In what way is it limited?
>> >> AFAIK, it's similar to commons-logging.
>> >>
>> >> No there are limitations on appenders additions, you cannot add, you
>> must
>> > set them all, at least one issue i faced.
>>
>> Sorry, I don't follow.
>>
>> Look at Log Viewer code changes:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=41788
>
>
>> >
>> >
>> >> > I remember when starting using jmeter (I knew at that time log4j,
>> >> > commons-logging) I had to modify log level somewhere, I search a
>> while
>> >> > because it was a new mechanism to learn (had jmeter relied on
>> existing
>> >> conf
>> >> > of log4j or other I would have found this very rapidly, ActiveMQ for
>> >> > example uses commons-logging, slf4j and possibly logback).
>> >> >
>> >> >> Would we lose any functionality by changing?
>> >> >>
>> >> > I don't think so.
>> >> > But maybe you should detail all the features and we could check.
>> >>
>> >> That's quite difficult to do.
>> >>
>> >> >>
>> >> >> It took a lot of work to get everything set up properly; and will
>> be a
>> >> >> very major undertaking to change everything.
>> >> >> It's not just changes to class import statements and creating a
>> >> >> different logger.
>> >> >> There's documentation, and the way we use properties to control
>> >> >> logging different classes and packages.
>> >> >> If that changes, it could break some user installations.
>> >> >>
>> >> >
>> >> > I agree it changes but log4j, commons-logging, slf4j are such
>> standard
>> >> that
>> >> > it's very easy to find info, for example look at stackoverflow
>> >> statistics:
>> >> >
>> >> > - http://stackoverflow.com/questions/tagged/slf4j : 390 questions
>> >> > - http://stackoverflow.com/questions/tagged/log4j : 2170
>> questions
>> >> > - http://stackoverflow.com/questions/tagged/logback : 320
>> questions
>> >> > -
>> http://stackoverflow.com/questions/tagged/apache-commons-logging :
>> >> 61
>> >> > questions
>> >> > - logkit, avalon, excalibur : 0 questions
>> >> >
>> >>
>> >> So? AFAICT, most of that relates to using and implementing logging,
>> >> rather than configuring logging levels, which is the main issue for
>> >> end users.
>> >>
>> >> They also relate to configuring , what i am trying to sat is that
>> there is
>> > much more docs on these new libs as on excalibur one.
>>
>> The only configuration that the end-user needs to do is to set the log
>> level for the package(s).
>>
> It would be the same for log4j, logback
>
>>
>> That aspect of configuration is quite sophisticated in Avalon.
>> As well as quite easy to use (and trivial for developers, as the name
>> is automatically created from the class name).
>>
> Same for log4j, logback
>
>>
>> How would that work in other logging implementations?
>> It's important that logging can be easily selectively enabled.
>>
>> Same for log4j, logback
>
>
> > Regarding user, see my argument on contributors , plugin writers,
> > developpers
>
> >>
> >> > Users will also need to get learn a different way of controlling
> logging.
> >> >>
> >> >>
> >> > We could rely on underlying product documentation which is quite well
> >> known
> >> > (log4j , logback ) instead of creating our own mechanism .
> >> > We could then remove all Logging Configuration paragraph from
> >> > jmeter.properties.
> >> >
> >> >>
> >> >> >
> >> >> > Perhaps, some issue with the logback dual licences (EPL and LGPL).
> I'm
> >> >> not
> >> >> > sure if we can used the logback with only the choice of EPL
> licence...
> >> >> >
> >> >> >
> >> >> > The commons-logging and the Log4j are under AL2.0, seems better to
> >> use an
> >> >> > ASF product in an ASF product? ;-)
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> I think we should really remove dependency on Apache Excalibur.
> >> >>
> >> >> We still use parts of Excalibur for JDBC pooling.
> >> >>
> >> >> I don't see the point of pooling if you are testing JDBC; it then
> >> >> becomes as much a test of the pool rather than JDBC.
> >> >>
> >> > Don't understand this
> >> >
> >> >>
> >> >> If we do want to support pooling, it should be selectable.
> >> >> However I don't know if there is a standard Pooling API, so that
> might
> >> >> not be possible.
> >> >>
> >> >> Why not use commons-dbcp or tomcat-pool for this ?
> >>
> >> See separate thread.
> >>
> >> >> >>
> >> >> >>
> >> >> >> Regards
> >> >> >>
> >> >> >> Philippe
> >> >> >> // Copying dialog from another thread:
> >> >> >>
> >> >> >> Philippe says
> >> >> >> >> As we are now in these big changes (static final, interface
> >> cleanup
> >> >> ...
> >> >> >> )
> >> >> >> >> Sebb, milamber is it ok for you if I start migration to
> >> >> commons-logging
> >> >> >> ?
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> Milamber says:
> >> >> >> > Why commons-loggings (not updated since 2008)?
> >> >> >>
> >> >> >> Sebb says:
> >> >> >> AIUI it's not been updated since it works; there has been no need
> to
> >> >> update
> >> >> >> it.
> >> >> >>
> >> >> >> > Log4J ?
> >> >> >>
> >> >> >> > or directly java.util.logging.*?
> >> >> >>
> >> >> >> That's broken, according to what I read.
> >> >> >>
> >> >> >> On Mon, Jan 23, 2012 at 1:39 PM, Philippe Mouawad <
> >> >> >> philippe.moua...@gmail.com> wrote:
> >> >> >>
> >> >> >> > Hello Sebb,
> >> >> >> > My responses below.
> >> >> >> > Regards
> >> >> >> > Philippe
> >> >> >> >
> >> >> >> > On Mon, Jan 23, 2012 at 1:02 PM, sebb <seb...@gmail.com> wrote:
> >> >> >> >
> >> >> >> >> On 23 January 2012 06:49, Philippe Mouawad <
> >> >> philippe.moua...@gmail.com>
> >> >> >> >> wrote:
> >> >> >> >> > Regarding logging,
> >> >> >> >> > It CAN Go fast if we share work and each of us takes one SRC
> >> >> folder.
> >> >> >> >> > It's à matter f search replace for 90%.
> >> >> >> >>
> >> >> >> >> It's still the same amount of wor
>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
--
Cordialement.
Philippe Mouawad.
