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.moua...@gmail.com> wrote: > Hello Sebb, > My responses below. > Regards > Philippe > > On Mon, Jan 23, 2012 at 1:02 PM, sebb <seb...@gmail.com> wrote: > >> On 23 January 2012 06:49, Philippe Mouawad <philippe.moua...@gmail.com> >> wrote: >> > Regarding logging, >> > It CAN Go fast if we share work and each of us takes one SRC folder. >> > It's à matter f search replace for 90%. >> >> It's still the same amount of 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 <ans...@gmail.com> wrote: >> >> On Sun, Jan 22, 2012 at 9:28 PM, sebb <seb...@gmail.com> wrote: >> >>> On 23 January 2012 01:46, Anthony Johnson <ans...@gmail.com> wrote: >> >>>> On Sun, Jan 22, 2012 at 8:29 PM, sebb <seb...@gmail.com> wrote: >> >>>>> >> >>>>> On 22 January 2012 13:04, Philippe Mouawad < >> philippe.moua...@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.
