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 Mon, 21 Jan 2013 21:15:55 GMT
Hello Sebb, Milamber, Rainer,

Reminder for this.
Regards
Philippe

On Thu, Aug 23, 2012 at 12:44 AM, 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>
>> wrote:
>> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <sebbaz@gmail.com> wrote:
>> >
>> >> On 22 August 2012 17:52, Milamber <milamber@apache.org> wrote:
>> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
>> >> > philippe.mouawad@gmail.com> 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/
>
> 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)
>
> For new comers, they will look at what Libraries are used, too old ones
> car fear or can be a negative point.
>
> Furthermore are we sure performances of theseew libraries are not better ?
> ( you will kill this argument ;) )
>
>
>> > 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.
>
>
>
>> > 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.
> 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.
>
>
>
>


-- 
Cordialement.
Philippe Mouawad.

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