You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <ph...@gmail.com> on 2012/08/22 17:34:11 UTC
Re: Apache Excalibur Logger
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 think we should really remove dependency on Apache Excalibur.
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 <se...@gmail.com> wrote:
>
>> On 23 January 2012 06:49, Philippe Mouawad <ph...@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 <an...@gmail.com> wrote:
>> >> On Sun, Jan 22, 2012 at 9:28 PM, sebb <se...@gmail.com> wrote:
>> >>> On 23 January 2012 01:46, Anthony Johnson <an...@gmail.com> wrote:
>> >>>> On Sun, Jan 22, 2012 at 8:29 PM, sebb <se...@gmail.com> wrote:
>> >>>>>
>> >>>>> On 22 January 2012 13:04, Philippe Mouawad <
>> philippe.mouawad@gmail.com>
>> > wrote:
>> >>>>> > Hello,
>> >>>>> > I noticed there was some plan to remove Excalibur logger
>> dependency.
>> >>>>> > What is the new selected component to replace it ?
>> >>>>> >
>> >>>>> > - log4j
>> >>>>> > - slf4J+logback
>> >>>>>
>> >>>>> Given that the main focus of JMeter is HTTP, and we use Apache
>> >>>>> HttpClient, if we do replace logging it will be sensible to use the
>> >>>>> same, i.e. Commons Logging.
>> >>>>>
>> >>>>> But it is a huge job to do this; every single file that uses logging
>> >>>>> will need to be updated.
>> >>>>>
>> >>>>> As well as changing all the documentation, config files etc.
>> >>>>>
>> >>>>> >
>> >>>>> > When do we plan this migration ?
>> >>>>>
>> >>>>> Not yet.
>> >>>>>
>> >>>>> > Working on 41788
>> >>>>> > <https://issues.apache.org/bugzilla/show_bug.cgi?id=41788>I
>> noticed
>> >>>>> > javadocs for excalibur where no more available on internet.
>> >>>>> >
>> >>>>> > I suppose the same question will arise regarding DataBase Sampler
>> > pool.
>> >>>>> > What are the candidates:
>> >>>>> >
>> >>>>> > - Tomcat JDBC Pool :
>> >>>>> > http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
>> >>>>> > - Commons DBCP ?
>> >>>>>
>> >>>>> I wonder whether there's really any point supporting database
>> pooling
>> >>>>> at all, given that the focus of JMeter is on independent test
>> threads.
>> >>>>>
>> >>>>
>> >>>> JMeter definitely needs persistent database connections which is
>> >>>> easily accomplished with database pooling. JMeter loses usefulness
>> if
>> >>>> it has to open a connection at sample time since this is a lot more
>> >>>> expensive than running optimized SQL.
>> >>>>
>> >>>> Also, some database features rely on persistent connections to be
>> >>>> optimized such as PreparedStatement caches.
>> >>>
>> >>> JMeter uses persistent connections; the connection is established by:
>> >>>
>> >>>
>> >
>> http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Connection_Configuration
>> >>>
>> >>> This is a different matter from sharing connections between threads.
>> >>>
>> >>> The per-thread (non-shared) pool is currently implemented as a pool
>> >>> size of 1 per thread.
>> >>>
>> >>
>> >> The preferred way(per the sarcastic "why use pooling" in the docs:-)
>> >> is not very nice code-wise. If I have a 1,000 thread test then I will
>> >> have a 1,000 excaliber thread pool objects in memory and 1,000
>> >> per-thread poolMap objects. Getting rid of pooling in JMeter would
>> >> definitely make this code better.
>> >>
>> >> On the other hand, their are nice features from the pooling such as
>> >> connection testing, keep-alives and such. Some of those would need to
>> >> be implemented if you guys decided to rip out pooling.
>> >>
>> >> Regardless, you responded to my only concern and I learned
>> >> something(despite having written several JDBC Test Plans in the
>> >> past:-/)
>> >>
>> >>>>> Adding pooling effectively means that JMeter is testing the pooling
>> as
>> >>>>> well as the database.
>> >>>>>
>> >>>>> > I made some Load tests for an ECommerce site comparing the 2 pools
>> > and the
>> >>>>> > first one seems to be a little better performing (specially in
>> > exhaustion
>> >>>>> > cases)
>> >>>>> >
>> >>>>> > although Commons DBCP quality is great.
>> >>>>>
>> >>>>> I don't think database pooling is really necessary for JMeter, so
>> the
>> >>>>> performance is not a big issue; tests that want to exercise a
>> database
>> >>>>> should not be using pooling - or at least should not be using a
>> >>>>> pooling solution which is fixed by JMeter.
>> >>>>>
>> >>>>> I don't know whether it's possible to create a datasource which
>> >>>>> includes pooling, if so, then that is the way to go - i.e. support
>> >>>>> data sources (I don't think we do currently).
>> >>>>>
>> >>>>> >
>> >>>>> > --
>> >>>>> > Cordialement.
>> >>>>> > Philippe Mouawad.
>> >>
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>
--
Cordialement.
Philippe Mouawad.
Re: Apache Excalibur Logger
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <se...@gmail.com> wrote:
>>
>>> On 22 August 2012 23:44, Philippe Mouawad <ph...@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 <se...@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.
Re: Apache Excalibur Logger
Posted by Philippe Mouawad <ph...@gmail.com>.
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<javascript:_e({}, 'cvml', 'sebbaz@gmail.com');>
> > wrote:
>
>> On 22 August 2012 23:44, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:_e({}, 'cvml', '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:_e({}, 'cvml', 'philippe.mouawad@gmail.com');>
>> <javascript:;>>
>> >> wrote:
>> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <sebbaz@gmail.com<javascript:_e({}, 'cvml', 'sebbaz@gmail.com');><javascript:;>>
>> >> wrote:
>> >> >
>> >> >> On 22 August 2012 17:52, Milamber <milamber@apache.org<javascript:_e({}, 'cvml', 'milamber@apache.org');><javascript:;>>
>> >> wrote:
>> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
>> >> >> > philippe.mouawad@gmail.com <javascript:_e({}, 'cvml',
>> '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 <se...@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.
Re: Apache Excalibur Logger
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <se...@gmail.com> wrote:
> On 22 August 2012 23:44, Philippe Mouawad <ph...@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 <se...@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 <se...@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 <se...@gmail.com>
> >> wrote:
> >> >> >> >> >>>>>
> >> >> >> >> >>>>> On 22 January 2012 13:04, Philippe Mouawad <
> >> >> >> >> philippe.mouawad@gmail.com>
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>
--
Cordialement.
Philippe Mouawad.
Re: Apache Excalibur Logger
Posted by sebb <se...@gmail.com>.
On 22 August 2012 23:44, Philippe Mouawad <ph...@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 <se...@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 <an...@gmail.com>
>> >> >> wrote:
>> >> >> >> >> On Sun, Jan 22, 2012 at 9:28 PM, sebb <se...@gmail.com>
>> wrote:
>> >> >> >> >>> On 23 January 2012 01:46, Anthony Johnson <an...@gmail.com>
>> >> wrote:
>> >> >> >> >>>> On Sun, Jan 22, 2012 at 8:29 PM, sebb <se...@gmail.com>
>> wrote:
>> >> >> >> >>>>>
>> >> >> >> >>>>> On 22 January 2012 13:04, Philippe Mouawad <
>> >> >> >> philippe.mouawad@gmail.com>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Apache Excalibur Logger
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <ph...@gmail.com>
>> wrote:
>> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <se...@gmail.com> wrote:
>> >
>> >> On 22 August 2012 17:52, Milamber <mi...@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 <se...@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 <se...@gmail.com>
>> wrote:
>> >> >> >> >>> On 23 January 2012 01:46, Anthony Johnson <an...@gmail.com>
>> >> wrote:
>> >> >> >> >>>> On Sun, Jan 22, 2012 at 8:29 PM, sebb <se...@gmail.com>
>> wrote:
>> >> >> >> >>>>>
>> >> >> >> >>>>> On 22 January 2012 13:04, Philippe Mouawad <
>> >> >> >> philippe.mouawad@gmail.com>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>
--
Cordialement.
Philippe Mouawad.
Re: Apache Excalibur Logger
Posted by Philippe Mouawad <ph...@gmail.com>.
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/
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 <se...@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 <an...@gmail.com>
> >> >> wrote:
> >> >> >> >> On Sun, Jan 22, 2012 at 9:28 PM, sebb <se...@gmail.com>
> wrote:
> >> >> >> >>> On 23 January 2012 01:46, Anthony Johnson <an...@gmail.com>
> >> wrote:
> >> >> >> >>>> On Sun, Jan 22, 2012 at 8:29 PM, sebb <se...@gmail.com>
> wrote:
> >> >> >> >>>>>
> >> >> >> >>>>> On 22 January 2012 13:04, Philippe Mouawad <
> >> >> >> philippe.mouawad@gmail.com>
>
--
Cordialement.
Philippe Mouawad.
Re: Apache Excalibur Logger
Posted by sebb <se...@gmail.com>.
On 22 August 2012 21:43, Philippe Mouawad <ph...@gmail.com> wrote:
> On Wed, Aug 22, 2012 at 7:21 PM, sebb <se...@gmail.com> wrote:
>
>> On 22 August 2012 17:52, Milamber <mi...@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.
> Other features I see:
>
> - Parameterized log messages :
> http://slf4j.org/faq.html#logging_performance
We already use the if enabled wrappers.
> - 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.
>
> What's wrong with the existing functionality?
>>
> it is based on a retired project (Excalibur). It kind of hurts me.
Irrelevant if it works.
> 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.
> 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.
>
> 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 <se...@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 <an...@gmail.com>
>> >> wrote:
>> >> >> >> On Sun, Jan 22, 2012 at 9:28 PM, sebb <se...@gmail.com> wrote:
>> >> >> >>> On 23 January 2012 01:46, Anthony Johnson <an...@gmail.com>
>> wrote:
>> >> >> >>>> On Sun, Jan 22, 2012 at 8:29 PM, sebb <se...@gmail.com> wrote:
>> >> >> >>>>>
>> >> >> >>>>> On 22 January 2012 13:04, Philippe Mouawad <
>> >> >> philippe.mouawad@gmail.com>
>> >> >> > wrote:
>> >> >> >>>>> > Hello,
>> >> >> >>>>> > I noticed there was some plan to remove Excalibur logger
>> >> >> dependency.
>> >> >> >>>>> > What is the new selected component to replace it ?
>> >> >> >>>>> >
>> >> >> >>>>> > - log4j
>> >> >> >>>>> > - slf4J+logback
>> >> >> >>>>>
>> >> >> >>>>> Given that the main focus of JMeter is HTTP, and we use Apache
>> >> >> >>>>> HttpClient, if we do replace logging it will be sensible to use
>> >> the
>> >> >> >>>>> same, i.e. Commons Logging.
>> >> >> >>>>>
>> >> >> >>>>> But it is a huge job to do this; every single file that uses
>> >> logging
>> >> >> >>>>> will need to be updated.
>> >> >> >>>>>
>> >> >> >>>>> As well as changing all the documentation, config files etc.
>> >> >> >>>>>
>> >> >> >>>>> >
>> >> >> >>>>> > When do we plan this migration ?
>> >> >> >>>>>
>> >> >> >>>>> Not yet.
>> >> >> >>>>>
>> >> >> >>>>> > Working on 41788
>> >> >> >>>>> > <https://issues.apache.org/bugzilla/show_bug.cgi?id=41788>I
>> >> >> noticed
>> >> >> >>>>> > javadocs for excalibur where no more available on internet.
>> >> >> >>>>> >
>> >> >> >>>>> > I suppose the same question will arise regarding DataBase
>> >> Sampler
>> >> >> > pool.
>> >> >> >>>>> > What are the candidates:
>> >> >> >>>>> >
>> >> >> >>>>> > - Tomcat JDBC Pool :
>> >> >> >>>>> > http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
>> >> >> >>>>> > - Commons DBCP ?
>> >> >> >>>>>
>> >> >> >>>>> I wonder whether there's really any point supporting database
>> >> >> pooling
>> >> >> >>>>> at all, given that the focus of JMeter is on independent test
>> >> >> threads.
>> >> >> >>>>>
>> >> >> >>>>
>> >> >> >>>> JMeter definitely needs persistent database connections which is
>> >> >> >>>> easily accomplished with database pooling. JMeter loses
>> usefulness
>> >> >> if
>> >> >> >>>> it has to open a connection at sample time since this is a lot
>> more
>> >> >> >>>> expensive than running optimized SQL.
>> >> >> >>>>
>> >> >> >>>> Also, some database features rely on persistent connections to
>> be
>> >> >> >>>> optimized such as PreparedStatement caches.
>> >> >> >>>
>> >> >> >>> JMeter uses persistent connections; the connection is established
>> >> by:
>> >> >> >>>
>> >> >> >>>
>> >> >> >
>> >> >>
>> >>
>> http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Connection_Configuration
>> >> >> >>>
>> >> >> >>> This is a different matter from sharing connections between
>> threads.
>> >> >> >>>
>> >> >> >>> The per-thread (non-shared) pool is currently implemented as a
>> pool
>> >> >> >>> size of 1 per thread.
>> >> >> >>>
>> >> >> >>
>> >> >> >> The preferred way(per the sarcastic "why use pooling" in the
>> docs:-)
>> >> >> >> is not very nice code-wise. If I have a 1,000 thread test then I
>> >> will
>> >> >> >> have a 1,000 excaliber thread pool objects in memory and 1,000
>> >> >> >> per-thread poolMap objects. Getting rid of pooling in JMeter
>> would
>> >> >> >> definitely make this code better.
>> >> >> >>
>> >> >> >> On the other hand, their are nice features from the pooling such
>> as
>> >> >> >> connection testing, keep-alives and such. Some of those would
>> need
>> >> to
>> >> >> >> be implemented if you guys decided to rip out pooling.
>> >> >> >>
>> >> >> >> Regardless, you responded to my only concern and I learned
>> >> >> >> something(despite having written several JDBC Test Plans in the
>> >> >> >> past:-/)
>> >> >> >>
>> >> >> >>>>> Adding pooling effectively means that JMeter is testing the
>> >> pooling
>> >> >> as
>> >> >> >>>>> well as the database.
>> >> >> >>>>>
>> >> >> >>>>> > I made some Load tests for an ECommerce site comparing the 2
>> >> pools
>> >> >> > and the
>> >> >> >>>>> > first one seems to be a little better performing (specially
>> in
>> >> >> > exhaustion
>> >> >> >>>>> > cases)
>> >> >> >>>>> >
>> >> >> >>>>> > although Commons DBCP quality is great.
>> >> >> >>>>>
>> >> >> >>>>> I don't think database pooling is really necessary for JMeter,
>> so
>> >> >> the
>> >> >> >>>>> performance is not a big issue; tests that want to exercise a
>> >> >> database
>> >> >> >>>>> should not be using pooling - or at least should not be using a
>> >> >> >>>>> pooling solution which is fixed by JMeter.
>> >> >> >>>>>
>> >> >> >>>>> I don't know whether it's possible to create a datasource which
>> >> >> >>>>> includes pooling, if so, then that is the way to go - i.e.
>> support
>> >> >> >>>>> data sources (I don't think we do currently).
>> >> >> >>>>>
>> >> >> >>>>> >
>> >> >> >>>>> > --
>> >> >> >>>>> > Cordialement.
>> >> >> >>>>> > Philippe Mouawad.
>> >> >> >>
>> >> >> >
>> >> >> > --
>> >> >> > Cordialement.
>> >> >> > Philippe Mouawad.
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Cordialement.
>> >> > Philippe Mouawad.
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Cordialement.
>> >> Philippe Mouawad.
>> >>
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Apache Excalibur Logger
Posted by Philippe Mouawad <ph...@gmail.com>.
On Wed, Aug 22, 2012 at 7:21 PM, sebb <se...@gmail.com> wrote:
> On 22 August 2012 17:52, Milamber <mi...@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 ?
Other features I see:
- Parameterized log messages :
http://slf4j.org/faq.html#logging_performance
- Marker objects : see
-
http://stackoverflow.com/questions/10766411/overriding-the-logging-methods-logger-warn-in-slf4j,
- http://logback.qos.ch/manual/layouts.html#Evaluators
What's wrong with the existing functionality?
>
it is based on a retired project (Excalibur). It kind of hurts me.
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
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.
>
> 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
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 ?
> >>
> >>
> >> 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 <se...@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 <an...@gmail.com>
> >> wrote:
> >> >> >> On Sun, Jan 22, 2012 at 9:28 PM, sebb <se...@gmail.com> wrote:
> >> >> >>> On 23 January 2012 01:46, Anthony Johnson <an...@gmail.com>
> wrote:
> >> >> >>>> On Sun, Jan 22, 2012 at 8:29 PM, sebb <se...@gmail.com> wrote:
> >> >> >>>>>
> >> >> >>>>> On 22 January 2012 13:04, Philippe Mouawad <
> >> >> philippe.mouawad@gmail.com>
> >> >> > wrote:
> >> >> >>>>> > Hello,
> >> >> >>>>> > I noticed there was some plan to remove Excalibur logger
> >> >> dependency.
> >> >> >>>>> > What is the new selected component to replace it ?
> >> >> >>>>> >
> >> >> >>>>> > - log4j
> >> >> >>>>> > - slf4J+logback
> >> >> >>>>>
> >> >> >>>>> Given that the main focus of JMeter is HTTP, and we use Apache
> >> >> >>>>> HttpClient, if we do replace logging it will be sensible to use
> >> the
> >> >> >>>>> same, i.e. Commons Logging.
> >> >> >>>>>
> >> >> >>>>> But it is a huge job to do this; every single file that uses
> >> logging
> >> >> >>>>> will need to be updated.
> >> >> >>>>>
> >> >> >>>>> As well as changing all the documentation, config files etc.
> >> >> >>>>>
> >> >> >>>>> >
> >> >> >>>>> > When do we plan this migration ?
> >> >> >>>>>
> >> >> >>>>> Not yet.
> >> >> >>>>>
> >> >> >>>>> > Working on 41788
> >> >> >>>>> > <https://issues.apache.org/bugzilla/show_bug.cgi?id=41788>I
> >> >> noticed
> >> >> >>>>> > javadocs for excalibur where no more available on internet.
> >> >> >>>>> >
> >> >> >>>>> > I suppose the same question will arise regarding DataBase
> >> Sampler
> >> >> > pool.
> >> >> >>>>> > What are the candidates:
> >> >> >>>>> >
> >> >> >>>>> > - Tomcat JDBC Pool :
> >> >> >>>>> > http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
> >> >> >>>>> > - Commons DBCP ?
> >> >> >>>>>
> >> >> >>>>> I wonder whether there's really any point supporting database
> >> >> pooling
> >> >> >>>>> at all, given that the focus of JMeter is on independent test
> >> >> threads.
> >> >> >>>>>
> >> >> >>>>
> >> >> >>>> JMeter definitely needs persistent database connections which is
> >> >> >>>> easily accomplished with database pooling. JMeter loses
> usefulness
> >> >> if
> >> >> >>>> it has to open a connection at sample time since this is a lot
> more
> >> >> >>>> expensive than running optimized SQL.
> >> >> >>>>
> >> >> >>>> Also, some database features rely on persistent connections to
> be
> >> >> >>>> optimized such as PreparedStatement caches.
> >> >> >>>
> >> >> >>> JMeter uses persistent connections; the connection is established
> >> by:
> >> >> >>>
> >> >> >>>
> >> >> >
> >> >>
> >>
> http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Connection_Configuration
> >> >> >>>
> >> >> >>> This is a different matter from sharing connections between
> threads.
> >> >> >>>
> >> >> >>> The per-thread (non-shared) pool is currently implemented as a
> pool
> >> >> >>> size of 1 per thread.
> >> >> >>>
> >> >> >>
> >> >> >> The preferred way(per the sarcastic "why use pooling" in the
> docs:-)
> >> >> >> is not very nice code-wise. If I have a 1,000 thread test then I
> >> will
> >> >> >> have a 1,000 excaliber thread pool objects in memory and 1,000
> >> >> >> per-thread poolMap objects. Getting rid of pooling in JMeter
> would
> >> >> >> definitely make this code better.
> >> >> >>
> >> >> >> On the other hand, their are nice features from the pooling such
> as
> >> >> >> connection testing, keep-alives and such. Some of those would
> need
> >> to
> >> >> >> be implemented if you guys decided to rip out pooling.
> >> >> >>
> >> >> >> Regardless, you responded to my only concern and I learned
> >> >> >> something(despite having written several JDBC Test Plans in the
> >> >> >> past:-/)
> >> >> >>
> >> >> >>>>> Adding pooling effectively means that JMeter is testing the
> >> pooling
> >> >> as
> >> >> >>>>> well as the database.
> >> >> >>>>>
> >> >> >>>>> > I made some Load tests for an ECommerce site comparing the 2
> >> pools
> >> >> > and the
> >> >> >>>>> > first one seems to be a little better performing (specially
> in
> >> >> > exhaustion
> >> >> >>>>> > cases)
> >> >> >>>>> >
> >> >> >>>>> > although Commons DBCP quality is great.
> >> >> >>>>>
> >> >> >>>>> I don't think database pooling is really necessary for JMeter,
> so
> >> >> the
> >> >> >>>>> performance is not a big issue; tests that want to exercise a
> >> >> database
> >> >> >>>>> should not be using pooling - or at least should not be using a
> >> >> >>>>> pooling solution which is fixed by JMeter.
> >> >> >>>>>
> >> >> >>>>> I don't know whether it's possible to create a datasource which
> >> >> >>>>> includes pooling, if so, then that is the way to go - i.e.
> support
> >> >> >>>>> data sources (I don't think we do currently).
> >> >> >>>>>
> >> >> >>>>> >
> >> >> >>>>> > --
> >> >> >>>>> > Cordialement.
> >> >> >>>>> > Philippe Mouawad.
> >> >> >>
> >> >> >
> >> >> > --
> >> >> > Cordialement.
> >> >> > Philippe Mouawad.
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Cordialement.
> >> > Philippe Mouawad.
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >> --
> >> Cordialement.
> >> Philippe Mouawad.
> >>
>
--
Cordialement.
Philippe Mouawad.
Re: Apache Excalibur Logger
Posted by sebb <se...@gmail.com>.
On 22 August 2012 17:52, Milamber <mi...@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?
What's wrong with the existing functionality?
Would we lose any functionality by changing?
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.
Users will also need to get learn a different way of controlling logging.
>
>
> 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.
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.
>>
>>
>> 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 <se...@gmail.com> wrote:
>> >
>> >> On 23 January 2012 06:49, Philippe Mouawad <ph...@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 <an...@gmail.com>
>> wrote:
>> >> >> On Sun, Jan 22, 2012 at 9:28 PM, sebb <se...@gmail.com> wrote:
>> >> >>> On 23 January 2012 01:46, Anthony Johnson <an...@gmail.com> wrote:
>> >> >>>> On Sun, Jan 22, 2012 at 8:29 PM, sebb <se...@gmail.com> wrote:
>> >> >>>>>
>> >> >>>>> On 22 January 2012 13:04, Philippe Mouawad <
>> >> philippe.mouawad@gmail.com>
>> >> > wrote:
>> >> >>>>> > Hello,
>> >> >>>>> > I noticed there was some plan to remove Excalibur logger
>> >> dependency.
>> >> >>>>> > What is the new selected component to replace it ?
>> >> >>>>> >
>> >> >>>>> > - log4j
>> >> >>>>> > - slf4J+logback
>> >> >>>>>
>> >> >>>>> Given that the main focus of JMeter is HTTP, and we use Apache
>> >> >>>>> HttpClient, if we do replace logging it will be sensible to use
>> the
>> >> >>>>> same, i.e. Commons Logging.
>> >> >>>>>
>> >> >>>>> But it is a huge job to do this; every single file that uses
>> logging
>> >> >>>>> will need to be updated.
>> >> >>>>>
>> >> >>>>> As well as changing all the documentation, config files etc.
>> >> >>>>>
>> >> >>>>> >
>> >> >>>>> > When do we plan this migration ?
>> >> >>>>>
>> >> >>>>> Not yet.
>> >> >>>>>
>> >> >>>>> > Working on 41788
>> >> >>>>> > <https://issues.apache.org/bugzilla/show_bug.cgi?id=41788>I
>> >> noticed
>> >> >>>>> > javadocs for excalibur where no more available on internet.
>> >> >>>>> >
>> >> >>>>> > I suppose the same question will arise regarding DataBase
>> Sampler
>> >> > pool.
>> >> >>>>> > What are the candidates:
>> >> >>>>> >
>> >> >>>>> > - Tomcat JDBC Pool :
>> >> >>>>> > http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
>> >> >>>>> > - Commons DBCP ?
>> >> >>>>>
>> >> >>>>> I wonder whether there's really any point supporting database
>> >> pooling
>> >> >>>>> at all, given that the focus of JMeter is on independent test
>> >> threads.
>> >> >>>>>
>> >> >>>>
>> >> >>>> JMeter definitely needs persistent database connections which is
>> >> >>>> easily accomplished with database pooling. JMeter loses usefulness
>> >> if
>> >> >>>> it has to open a connection at sample time since this is a lot more
>> >> >>>> expensive than running optimized SQL.
>> >> >>>>
>> >> >>>> Also, some database features rely on persistent connections to be
>> >> >>>> optimized such as PreparedStatement caches.
>> >> >>>
>> >> >>> JMeter uses persistent connections; the connection is established
>> by:
>> >> >>>
>> >> >>>
>> >> >
>> >>
>> http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Connection_Configuration
>> >> >>>
>> >> >>> This is a different matter from sharing connections between threads.
>> >> >>>
>> >> >>> The per-thread (non-shared) pool is currently implemented as a pool
>> >> >>> size of 1 per thread.
>> >> >>>
>> >> >>
>> >> >> The preferred way(per the sarcastic "why use pooling" in the docs:-)
>> >> >> is not very nice code-wise. If I have a 1,000 thread test then I
>> will
>> >> >> have a 1,000 excaliber thread pool objects in memory and 1,000
>> >> >> per-thread poolMap objects. Getting rid of pooling in JMeter would
>> >> >> definitely make this code better.
>> >> >>
>> >> >> On the other hand, their are nice features from the pooling such as
>> >> >> connection testing, keep-alives and such. Some of those would need
>> to
>> >> >> be implemented if you guys decided to rip out pooling.
>> >> >>
>> >> >> Regardless, you responded to my only concern and I learned
>> >> >> something(despite having written several JDBC Test Plans in the
>> >> >> past:-/)
>> >> >>
>> >> >>>>> Adding pooling effectively means that JMeter is testing the
>> pooling
>> >> as
>> >> >>>>> well as the database.
>> >> >>>>>
>> >> >>>>> > I made some Load tests for an ECommerce site comparing the 2
>> pools
>> >> > and the
>> >> >>>>> > first one seems to be a little better performing (specially in
>> >> > exhaustion
>> >> >>>>> > cases)
>> >> >>>>> >
>> >> >>>>> > although Commons DBCP quality is great.
>> >> >>>>>
>> >> >>>>> I don't think database pooling is really necessary for JMeter, so
>> >> the
>> >> >>>>> performance is not a big issue; tests that want to exercise a
>> >> database
>> >> >>>>> should not be using pooling - or at least should not be using a
>> >> >>>>> pooling solution which is fixed by JMeter.
>> >> >>>>>
>> >> >>>>> I don't know whether it's possible to create a datasource which
>> >> >>>>> includes pooling, if so, then that is the way to go - i.e. support
>> >> >>>>> data sources (I don't think we do currently).
>> >> >>>>>
>> >> >>>>> >
>> >> >>>>> > --
>> >> >>>>> > Cordialement.
>> >> >>>>> > Philippe Mouawad.
>> >> >>
>> >> >
>> >> > --
>> >> > Cordialement.
>> >> > Philippe Mouawad.
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>> >
>> >
>> >
>> >
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
Re: Apache Excalibur Logger
Posted by Milamber <mi...@apache.org>.
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
>
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.
>
>
> 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 <se...@gmail.com> wrote:
> >
> >> On 23 January 2012 06:49, Philippe Mouawad <ph...@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 <an...@gmail.com>
> wrote:
> >> >> On Sun, Jan 22, 2012 at 9:28 PM, sebb <se...@gmail.com> wrote:
> >> >>> On 23 January 2012 01:46, Anthony Johnson <an...@gmail.com> wrote:
> >> >>>> On Sun, Jan 22, 2012 at 8:29 PM, sebb <se...@gmail.com> wrote:
> >> >>>>>
> >> >>>>> On 22 January 2012 13:04, Philippe Mouawad <
> >> philippe.mouawad@gmail.com>
> >> > wrote:
> >> >>>>> > Hello,
> >> >>>>> > I noticed there was some plan to remove Excalibur logger
> >> dependency.
> >> >>>>> > What is the new selected component to replace it ?
> >> >>>>> >
> >> >>>>> > - log4j
> >> >>>>> > - slf4J+logback
> >> >>>>>
> >> >>>>> Given that the main focus of JMeter is HTTP, and we use Apache
> >> >>>>> HttpClient, if we do replace logging it will be sensible to use
> the
> >> >>>>> same, i.e. Commons Logging.
> >> >>>>>
> >> >>>>> But it is a huge job to do this; every single file that uses
> logging
> >> >>>>> will need to be updated.
> >> >>>>>
> >> >>>>> As well as changing all the documentation, config files etc.
> >> >>>>>
> >> >>>>> >
> >> >>>>> > When do we plan this migration ?
> >> >>>>>
> >> >>>>> Not yet.
> >> >>>>>
> >> >>>>> > Working on 41788
> >> >>>>> > <https://issues.apache.org/bugzilla/show_bug.cgi?id=41788>I
> >> noticed
> >> >>>>> > javadocs for excalibur where no more available on internet.
> >> >>>>> >
> >> >>>>> > I suppose the same question will arise regarding DataBase
> Sampler
> >> > pool.
> >> >>>>> > What are the candidates:
> >> >>>>> >
> >> >>>>> > - Tomcat JDBC Pool :
> >> >>>>> > http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
> >> >>>>> > - Commons DBCP ?
> >> >>>>>
> >> >>>>> I wonder whether there's really any point supporting database
> >> pooling
> >> >>>>> at all, given that the focus of JMeter is on independent test
> >> threads.
> >> >>>>>
> >> >>>>
> >> >>>> JMeter definitely needs persistent database connections which is
> >> >>>> easily accomplished with database pooling. JMeter loses usefulness
> >> if
> >> >>>> it has to open a connection at sample time since this is a lot more
> >> >>>> expensive than running optimized SQL.
> >> >>>>
> >> >>>> Also, some database features rely on persistent connections to be
> >> >>>> optimized such as PreparedStatement caches.
> >> >>>
> >> >>> JMeter uses persistent connections; the connection is established
> by:
> >> >>>
> >> >>>
> >> >
> >>
> http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Connection_Configuration
> >> >>>
> >> >>> This is a different matter from sharing connections between threads.
> >> >>>
> >> >>> The per-thread (non-shared) pool is currently implemented as a pool
> >> >>> size of 1 per thread.
> >> >>>
> >> >>
> >> >> The preferred way(per the sarcastic "why use pooling" in the docs:-)
> >> >> is not very nice code-wise. If I have a 1,000 thread test then I
> will
> >> >> have a 1,000 excaliber thread pool objects in memory and 1,000
> >> >> per-thread poolMap objects. Getting rid of pooling in JMeter would
> >> >> definitely make this code better.
> >> >>
> >> >> On the other hand, their are nice features from the pooling such as
> >> >> connection testing, keep-alives and such. Some of those would need
> to
> >> >> be implemented if you guys decided to rip out pooling.
> >> >>
> >> >> Regardless, you responded to my only concern and I learned
> >> >> something(despite having written several JDBC Test Plans in the
> >> >> past:-/)
> >> >>
> >> >>>>> Adding pooling effectively means that JMeter is testing the
> pooling
> >> as
> >> >>>>> well as the database.
> >> >>>>>
> >> >>>>> > I made some Load tests for an ECommerce site comparing the 2
> pools
> >> > and the
> >> >>>>> > first one seems to be a little better performing (specially in
> >> > exhaustion
> >> >>>>> > cases)
> >> >>>>> >
> >> >>>>> > although Commons DBCP quality is great.
> >> >>>>>
> >> >>>>> I don't think database pooling is really necessary for JMeter, so
> >> the
> >> >>>>> performance is not a big issue; tests that want to exercise a
> >> database
> >> >>>>> should not be using pooling - or at least should not be using a
> >> >>>>> pooling solution which is fixed by JMeter.
> >> >>>>>
> >> >>>>> I don't know whether it's possible to create a datasource which
> >> >>>>> includes pooling, if so, then that is the way to go - i.e. support
> >> >>>>> data sources (I don't think we do currently).
> >> >>>>>
> >> >>>>> >
> >> >>>>> > --
> >> >>>>> > Cordialement.
> >> >>>>> > Philippe Mouawad.
> >> >>
> >> >
> >> > --
> >> > Cordialement.
> >> > Philippe Mouawad.
> >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
> >
> >
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
>