Hmm 2 questions just to ensure we are aligned and mail didn't loose
information:
- for trunk: do we move the version to 2.3-SNAPSHOT?
- for next release: i'm not sure what's the difference is at the moment but
any reason to not do a 2.3 from trunk? (asking from the jcache perspective
i upgraded to
If you ignore the container point - which for me is already blocking - you
have 2 issues with migratong to log4j2:
1. it is not mainstream compared to slf4j for instance so means once again
duplicating logging configs in user apps
2. what would give stability to jcs users? Commons logging was targ
Although I am a big fan of Log4j 2, there are use cases where more thought
needs to be given then just adopting it, SLF4J, JUL, etc.
The problem comes into play in in frameworks like Tomcat, TomEE or JBoss AS.
These frameworks need to perform logging but whatever they use has to be able
to meet
As an end user of libraries, I much prefer when they stick to using
log4j-api or slf4j-api instead of some annoying library-specific facade
which requires even more configuration to set up in the end. As long as I
can pull in log4j-api, log4j-core, and log4j-slf4j-impl, everything "just
works" esse
On 03.09.17 20:17, Romain Manni-Bucau wrote:
> Thanks Thomas
>
> Is it the same for the code? Just realised pom were not up to date too.
I released from a branch as some braking changes are already checked in
into trunk. I'd kindly ask you to do the same if you are planning for a
bugfix release.
On Sun, Sep 3, 2017 at 1:34 PM, Rob Tompkins wrote:
>
>
> > On Sep 3, 2017, at 1:39 PM, Benedikt Ritter wrote:
> >
> > Great work, thank you!
>
> +1
>
Well done indeed! :-)
Gary
>
> >
> >> Am 03.09.2017 um 08:21 schrieb Bruno P. Kinoshita :
> >>
> >> Hello,
> >>
> >> The Apache Commons Commu
> On Sep 3, 2017, at 1:39 PM, Benedikt Ritter wrote:
>
> Great work, thank you!
+1
>
>> Am 03.09.2017 um 08:21 schrieb Bruno P. Kinoshita :
>>
>> Hello,
>>
>> The Apache Commons Community is happy to announce the release of Apache
>> Commons
>> CSV 1.5. The Apache Commons CSV library prov
Had a test using cdi integration but moving the level test reduced
execution time from ~1.4 to 1.25 (normalized numbers). It was ror millions
of calls but still worth it IMO. Log impl was indeed jul ;).
Le 3 sept. 2017 20:16, "Thomas Vandahl" a écrit :
On 03.09.17 20:11, Romain Manni-Bucau wro
On Sun, Sep 3, 2017 at 12:12 PM, Thomas Vandahl wrote:
> On 03.09.17 20:05, Gary Gregory wrote:
> > Would that not duplicate what logging facades (like log4j-api) already
> > provide?
>
> You mean like commons-logging? Yeah, I understand that's not what is
> required here. Otherwise it could stay
Thanks Thomas
Is it the same for the code? Just realised pom were not up to date too.
Le 3 sept. 2017 20:06, "Thomas Vandahl" a écrit :
On 01.09.17 17:23, Romain Manni-Bucau wrote:
> 2.2 is out seems some days and jira seems to not have it yet, is it
> intended or it was just forgotten?
The l
On 03.09.17 20:11, Romain Manni-Bucau wrote:
> On the perf thing: isXXXEnabled can be costly by itself - see my last
> commit.
Could you please provide some numbers to this claim?
Bye, Thomas.
-
To unsubscribe, e-mail: dev-uns
On 03.09.17 20:05, Gary Gregory wrote:
> Would that not duplicate what logging facades (like log4j-api) already
> provide?
You mean like commons-logging? Yeah, I understand that's not what is
required here. Otherwise it could stay as it is. I believe that
especially a caching layer should be as li
On the perf thing: isXXXEnabled can be costly by itself - see my last
commit.
On the light jcs facade: this is what most projects do so +1. This doesnt
duplicate log4j one cause log4j is a user facing one where the lib one is
configure and provided at container level when relevant.
Le 3 sept. 201
Almost had the same except when using a lot of keys where a single lock is
an issue or a plain map which is still 4 times faster under a medium load
just doing gets (50 threads). Issue is we ignore if the underlying memcache
is thread safe which means we could avoid the composite cache
synchronizat
That would definitely duplicate effort. I've seen a few libraries out there
that abstract out logging only to make the default implementation slf4j or
log4j-api which just makes yet another hop of indirection.
On 3 September 2017 at 13:05, Gary Gregory wrote:
> On Sep 3, 2017 12:00, "Thomas Vand
On 01.09.17 17:23, Romain Manni-Bucau wrote:
> 2.2 is out seems some days and jira seems to not have it yet, is it
> intended or it was just forgotten?
The latter. Fixed it now.
Bye, Thomas
-
To unsubscribe, e-mail: dev-unsubsc
On Sep 3, 2017 12:00, "Thomas Vandahl" wrote:
On 03.09.17 09:02, Romain Manni-Bucau wrote:
> Once again the issue is the risk to break users and to ensure the api is
> consistent accross all libs (jcs, openjpa, tomee, cxf, activemq, commons,
> ...). It is clearly not "is it good or bad" and tomee
On 03.09.17 09:02, Romain Manni-Bucau wrote:
> Once again the issue is the risk to break users and to ensure the api is
> consistent accross all libs (jcs, openjpa, tomee, cxf, activemq, commons,
> ...). It is clearly not "is it good or bad" and tomee switch from log4j1 to
> jul reduced the number
On 02.09.17 20:04, Romain Manni-Bucau wrote:
> However reworking the logging in JCS can be interesting, current log usage
> is slow and sometimes in synchronized blocks so I guess we can be better.
Could you please mark places where this is the case? I spent quite some
effort to extract logging fr
On 02.09.17 10:41, Romain Manni-Bucau wrote:
> Ok, got the confirmation for the reflection fix.
>
> Now we lock in CompositeCache.get. Wonder if we could have a lock free
> MemoryCache implementation, at least for read side of things. Sounds doable
> using ConcurrentMap like algorithms but can req
Great work, thank you!
> Am 03.09.2017 um 08:21 schrieb Bruno P. Kinoshita :
>
> Hello,
>
> The Apache Commons Community is happy to announce the release of Apache
> Commons
> CSV 1.5. The Apache Commons CSV library provides a simple interface for
> reading
> and writing CSV files of various t
Le 2 sept. 2017 22:34, "Matt Sicker" a écrit :
Using JUL for any library, while dependency-free, is the worst of all
worlds as it creates a huge overhead in logging. The only workaround in
production applications is to disable logging to any logger tied to JUL,
and then you have the fun of debugg
22 matches
Mail list logo
