jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Apache Excalibur Logger
Date Tue, 04 Nov 2014 20:26:45 GMT
Hello,
Pinging again on this.

Log4j2 has astounding performances now and is stable, Excalibur is
deprecated, we should no more rely on deprecated libraries.
It is a risk on:

   - security level (if an issue affects a dead lib)
   - maintenance
   - documentation

As to configuration, see this kind of questions:

   -
   http://stackoverflow.com/questions/25465609/how-to-create-html-log-file-from-jmeter


Regards

Philippe

On Sun, Jun 30, 2013 at 12:04 AM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:

> 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 <sebbaz@gmail.com> wrote:
>>
>>> 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.
>>> >
>>>
>> 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.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 wor
>>
>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message