jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Apache Excalibur Logger
Date Mon, 21 Jan 2013 22:01:02 GMT
On 22 August 2012 23:44, Philippe Mouawad <philippe.mouawad@gmail.com> wrote:
> Last try to convince you :-)
>
> On Thursday, August 23, 2012, sebb wrote:
>
>> On 22 August 2012 21:43, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;>>
>> wrote:
>> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <sebbaz@gmail.com <javascript:;>>
>> wrote:
>> >
>> >> On 22 August 2012 17:52, Milamber <milamber@apache.org <javascript:;>>
>> wrote:
>> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
>> >> > philippe.mouawad@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.
>
>
> 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?

> 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.

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.

>
>
>> > 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).

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).

How would that work in other logging implementations?
It's important that logging can be easily selectively enabled.

> 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.mouawad@gmail.com> wrote:
>> >> >>
>> >> >> > Hello Sebb,
>> >> >> > My responses below.
>> >> >> > Regards
>> >> >> > Philippe
>> >> >> >
>> >> >> > On Mon, Jan 23, 2012 at 1:02 PM, sebb <sebbaz@gmail.com>
wrote:
>> >> >> >
>> >> >> >> On 23 January 2012 06:49, Philippe Mouawad <
>> >> philippe.mouawad@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 work, no matter how many
people do
>> it.
>> >> >> >> [Possibly more, if you allow for co-ordination overheads]
>> >> >> >>
>> >> >> >> Generally it's the last 10% that takes all the effort.
>> >> >> >>
>> >> >> > => I agree , I volunteer to do it if you agree after release.
>> >> >> >
>> >> >> >>
>> >> >> >> Definitely not something to be started just before a release.
>> >> >> >>
>> >> >> >> => It was not my intention, it is just after the release.
>> >> >> >
>> >> >> >
>> >> >> >> Also, we would still need to keep the jars unless we rewrote
>> >> >> >> OldSaveService - or made it optional.
>> >> >> >>
>> >> >> >> >
>> >> >> >> > Regarding pool i am not sure to  there is an datasourceelemnt
>> That
>> >> >> has à
>> >> >> >> > Maxpool property and looking at code it seemed the
 excalibur
>> >> >> datasource
>> >> >> >> > was using this property.
>> >> >> >> > Commons jdbc BasicDatasource was looking very close
to it.
>> >> >> >> >
>> >> >> >> > Regards
>> >> >> >> > Philippe
>> >> >> >> > On Monday, January 23, 2012, Anthony Johnson <ansoni@gmail.com>
>> >> >> wrote:
>> >> >> >> >> On Sun, Jan 22, 2012 at 9:28 PM, sebb <sebbaz@gmail.com>
>> wrote:
>> >> >> >> >>> On 23 January 2012 01:46, Anthony Johnson
<ansoni@gmail.com>
>> >> wrote:
>> >> >> >> >>>> On Sun, Jan 22, 2012 at 8:29 PM, sebb
<sebbaz@gmail.com>
>> wrote:
>> >> >> >> >>>>>
>> >> >> >> >>>>> On 22 January 2012 13:04, Philippe
Mouawad <
>> >> >> >> philippe.mouawad@gmail.com>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Mime
View raw message