Re: [jcs] logging

On Mon, Jun 2, 2014 at 1:20 AM, Romain Manni-Bucau wrote: > Well ATM log4j2 doesnt work well, didnt get time to dig into it but tested > last week for another topic and lost all my shutdown messages (guess > cleanup is called too early). > Please to check out trunk and give us some feedback! tru

Re: [jcs] logging

Well because [logging] was longly broken in a not flat classloading environment (didnt check last release but almost all logging facade got this issue at a point) and because almost nothing in TomEE stacks uses it, it is not as integrated as log4j, slf4j or JUL (which is the default). Main issue I

[continuum] BUILD FAILURE: Apache Commons BeanUtils - Apache Commons (Test build - see how to get round OOME)

Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=31793&projectId=65 Build statistics: State: Failed Previous State: Failed Started at: Mon 2 Jun 2014 06:20:06 + Finished at: Mon 2 Jun 2014 06:21:38 + Total time: 1m 32s Build Trigger: Schedul

Re: [jcs] logging

Romain Manni-Bucau wrote: > Hi > > I have two main point to discuss regarding the logging: > 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a > if (boolean) complexity and not go through the logging framework which can > imply several layers (filter, appender, handler, log

Re: [beanutils] Typo in RELEASE-NOTES.txt

Le 02/06/2014 02:36, Konstantin Kolinko a écrit : > There is a trivial copy-pasted typo in the release notes file: the > title for 1.9.1 changes on line 66 says "1.9.0". Fixed, thank you Konstantin. Emmanuel Bourg - To unsubsc

RE: [jcs] logging

Well ATM log4j2 doesnt work well, didnt get time to dig into it but tested last week for another topic and lost all my shutdown messages (guess cleanup is called too early). 3 would be an option if we dont rely on [logging] anymore but the impl directly which would be a regression IMHO + either wo

Re: svn commit: r1598071 - in /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs: auxiliary/disk/ engine/control/ engine/memory/ utils/logger/ utils/struct/

Am Sun, 1 Jun 2014 23:43:10 +0100 schrieb sebb : > On 1 June 2014 20:19, Romain Manni-Bucau > wrote: > > well it is for sure thread safe. Not sure I get why final and synch > > would be mandatory in this particular case (field will maybe be > > cached by thread but that's not an issue since the v

[beanutils] Typo in RELEASE-NOTES.txt

Hi! Congratulations on your BeanUtils 1.9.2 release. There is a trivial copy-pasted typo in the release notes file: the title for 1.9.1 changes on line 66 says "1.9.0". I think it is not worth creating a JIRA issue for this. [[[ Index: RELEASE-NOTES.txt =

RE: [jcs] logging

There is also log4j 2. Gary Original message From: Romain Manni-Bucau Date:06/01/2014 15:26 (GMT-05:00) To: Commons Developers List Subject: [jcs] logging Hi I have two main point to discuss regarding the logging: 1) LogHelper stuffI committed. Idea was to cache isDebugE

Re: [jcs] logging

On 1 June 2014 20:26, Romain Manni-Bucau wrote: > Hi > > I have two main point to discuss regarding the logging: > 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a if > (boolean) complexity and not go through the logging framework which can > imply several layers (filter, a

Re: svn commit: r1598071 - in /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs: auxiliary/disk/ engine/control/ engine/memory/ utils/logger/ utils/struct/

On 1 June 2014 20:19, Romain Manni-Bucau wrote: > well it is for sure thread safe. Not sure I get why final and synch would be > mandatory in this particular case (field will maybe be cached by thread but > that's not an issue since the value will be unique). non-final fields are not guaranteed t

Re: [MATH-1120] Needed opinion about support on variations in percentile calculation

I have gone through Wikipedia and R functions to get an understanding. My idea is to come up with different estimation techniques as strategies (Enums) and constrction inject during percentile object creation. The evaluate method could then use this estimation tecnhique to complete the computation

[jcs] logging

Hi I have two main point to discuss regarding the logging: 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a if (boolean) complexity and not go through the logging framework which can imply several layers (filter, appender, handler, logger...) for nothing and slow down cachi

Re: svn commit: r1598071 - in /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs: auxiliary/disk/ engine/control/ engine/memory/ utils/logger/ utils/struct/

well it is for sure thread safe. Not sure I get why final and synch would be mandatory in this particular case (field will maybe be cached by thread but that's not an issue since the value will be unique). I have nothing against a revert/reapply. I'll open a thread on logging btw. Romain Manni-

Re: svn commit: r1598071 - in /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs: auxiliary/disk/ engine/control/ engine/memory/ utils/logger/ utils/struct/

On 1 June 2014 18:54, Romain Manni-Bucau wrote: > > 2014-06-01 19:45 GMT+02:00 sebb : >> >> PING >> > > Pong, sorry, missed this one. > >> >> On 29 May 2014 03:00, sebb wrote: >> > On 28 May 2014 18:06, wrote: >> >> Author: rmannibucau >> >> Date: Wed May 28 17:06:12 2014 >> >> New Revision: 15

Re: svn commit: r1598071 - in /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs: auxiliary/disk/ engine/control/ engine/memory/ utils/logger/ utils/struct/

PING On 29 May 2014 03:00, sebb wrote: > On 28 May 2014 18:06, wrote: >> Author: rmannibucau >> Date: Wed May 28 17:06:12 2014 >> New Revision: 1598071 >> >> URL: http://svn.apache.org/r1598071 >> Log: >> using reentrant locks instead of old synchronized > > -1 > > This commit mixes two complet