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.moua...@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 <seb...@gmail.com> wrote: >> >>> On 22 August 2012 23:44, Philippe Mouawad <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:;>> >>> >> wrote: >>> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <seb...@gmail.com >>> <javascript:;>> >>> >> wrote: >>> >> > >>> >> >> On 22 August 2012 17:52, Milamber <milam...@apache.org >>> <javascript:;>> >>> >> wrote: >>> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad < >>> >> >> > 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. > > > > -- Cordialement. Philippe Mouawad.
