Re: [JCS] update to Log4j 2 facade API

[Romain Manni-Bucau]

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 debugging production issues without logs.



Which is the case for the server part in general since otherwise you get
way too much logs and they dont give you much in info mode. Also depend the
impl, in tomee we have some optimized handlers making it fast enough - even
faster than log4j2 in some marginal cases.

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 of issues about the logging quite a lot and increase
the logging consistency. There is no free lunch ;).


On 2 September 2017 at 13:04, Romain Manni-Bucau 
wrote:

> Hi Gary,
>
> Can only be done in 3.x since we can't break it in a minor.
>
> Now more on the ecosystem it would also mean dropping or forking JCS from
> TomEE since TomEE will stay JUL first for its stack and provides a light
> facade to switch to log4j2 (long story short: it is to avoid to enforce a
> lib users can not want or to avoid potential conflicts).
>
> 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.
>
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  rmannibucau> |
> LinkedIn  | JavaEE Factory
> 
>
> 2017-09-02 19:55 GMT+02:00 Gary Gregory :
>
> > Hi All,
> >
> > How about updating JCS from Commons Logging to Log4j 2?
> >
> > Gary
> >
>



--
Matt Sicker 

Re: [ANNOUNCE] Apache Commons CSV 1.5 has been released

[Benedikt Ritter]

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 types.
> 
> Source and binary distributions are available for download from the Apache
> Commons download site:
> http://commons.apache.org/proper/commons-csv/download_csv.cgi
> 
> When downloading, please verify signatures using the KEYS file available at 
> the
> above location.
> 
> Alternatively the release can be pulled via maven:
> 
>  org.apache.commons
>  commons-csv
>  1.5
> 
> 
> The release notes can be viewed at:
> http://www.apache.org/dist/commons/csv/RELEASE-NOTES.txt
> 
> For complete information on Commons CSV, including instructions on how to
> submit bug reports, patches, or suggestions for improvement, see the Apache
> Commons CSV website:
> 
> http://commons.apache.org/proper/commons-csv/
> 
> Best regards,
> Bruno P. Kinoshita
> on behalf of the Apache Commons community
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] JCache CDI integration

[Thomas Vandahl]

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 require more time than I have
> ATM to validate it :(. In other words: perf issue we can hit now is we
> don't scale in reads with thread number since we are synchronized with all
> the MemoryCache we provide OOTB.

I did several experiments with different locking mechanisms and found no
real improvement over the solution as it is now. You actually need to
lock on the key to make sure any write operation on that particular key
has finished before the result is returned. IOW, the overhead effort you
need to put into the management of this type of key locking is bigger
than the impact of the synchronization. At least that is what I found out.

Bye, Thomas.



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] update to Log4j 2 facade API

[Thomas Vandahl]

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 from synchronized blocks. (Please note that
lots of debug logging exists in synchronized blocks, but this is not
meant to be active in production)

Bye, Thomas.



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] update to Log4j 2 facade API

[Thomas Vandahl]

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 of issues about the logging quite a lot and increase
> the logging consistency. There is no free lunch ;).

I guess the only real solution is a logging stub in JCS that can be tied
to any logging sub-system by configuration. It's not that difficult to do.

Bye, Thomas.



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] update to Log4j 2 facade API

[Gary Gregory]

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 switch from log4j1
to
> jul reduced the number of issues about the logging quite a lot and
increase
> the logging consistency. There is no free lunch ;).

I guess the only real solution is a logging stub in JCS that can be tied
to any logging sub-system by configuration. It's not that difficult to do.


Would that not duplicate what logging facades (like log4j-api) already
provide?

Gary


Bye, Thomas.



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] update to Log4j 2 facade API

[Matt Sicker]

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 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 switch from log4j1
> to
> > jul reduced the number of issues about the logging quite a lot and
> increase
> > the logging consistency. There is no free lunch ;).
>
> I guess the only real solution is a logging stub in JCS that can be tied
> to any logging sub-system by configuration. It's not that difficult to do.
>
>
> Would that not duplicate what logging facades (like log4j-api) already
> provide?
>
> Gary
>
>
> Bye, Thomas.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Matt Sicker 

Re: [JCS] missing 2.2 release in jira?

[Thomas Vandahl]

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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] JCache CDI integration

[Romain Manni-Bucau]

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
synchronization when there is no aux cache and be close to a plain map, no?



Le 3 sept. 2017 19:53, "Thomas Vandahl"  a écrit :

> 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 require more time than I have
> > ATM to validate it :(. In other words: perf issue we can hit now is we
> > don't scale in reads with thread number since we are synchronized with
> all
> > the MemoryCache we provide OOTB.
>
> I did several experiments with different locking mechanisms and found no
> real improvement over the solution as it is now. You actually need to
> lock on the key to make sure any write operation on that particular key
> has finished before the result is returned. IOW, the overhead effort you
> need to put into the management of this type of key locking is bigger
> than the impact of the synchronization. At least that is what I found out.
>
> Bye, Thomas.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [JCS] update to Log4j 2 facade API

[Romain Manni-Bucau]

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. 2017 20:05, "Gary Gregory"  a écrit :

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 switch from log4j1
to
> jul reduced the number of issues about the logging quite a lot and
increase
> the logging consistency. There is no free lunch ;).

I guess the only real solution is a logging stub in JCS that can be tied
to any logging sub-system by configuration. It's not that difficult to do.


Would that not duplicate what logging facades (like log4j-api) already
provide?

Gary


Bye, Thomas.



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] update to Log4j 2 facade API

[Thomas Vandahl]

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 light-weight as possible and not
force people to use a certain log library. That's why JCS only depends
on commons-logging as this seemed to be a good choice at the time.

Bye, Thomas.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] update to Log4j 2 facade API

[Thomas Vandahl]

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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] missing 2.2 release in jira?

[Romain Manni-Bucau]

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 latter. Fixed it now.

Bye, Thomas


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] update to Log4j 2 facade API

[Gary Gregory]

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 as it is. I believe that
> especially a caching layer should be as light-weight as possible and not
> force people to use a certain log library.


That's what ALL libraries state, but IRL you need to code for logging, and
when you want to debug/trace/audit, then you want the best. My bias is
Log4j since I contribute actively there. When I mean the best, I also mean
access to features like markers at the facade level. On the many projects
I've seen a logging facade, the facade _eventually_ ends up mirroring the
underlying default API, whatever that is. So we end up ripping it out in
favor of coding to the facade.


> That's why JCS only depends
> on commons-logging as this seemed to be a good choice at the time.
>

At the time, yes. But today, the Log4j facade API is much richer IMO.

Gary

>
> Bye, Thomas.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [JCS] update to Log4j 2 facade API

[Romain Manni-Bucau]

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 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ANNOUNCE] Apache Commons CSV 1.5 has been released

[Rob Tompkins]

> 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 provides a simple interface for 
>> reading
>> and writing CSV files of various types.
>> 
>> Source and binary distributions are available for download from the Apache
>> Commons download site:
>> http://commons.apache.org/proper/commons-csv/download_csv.cgi
>> 
>> When downloading, please verify signatures using the KEYS file available at 
>> the
>> above location.
>> 
>> Alternatively the release can be pulled via maven:
>> 
>> org.apache.commons
>> commons-csv
>> 1.5
>> 
>> 
>> The release notes can be viewed at:
>> http://www.apache.org/dist/commons/csv/RELEASE-NOTES.txt
>> 
>> For complete information on Commons CSV, including instructions on how to
>> submit bug reports, patches, or suggestions for improvement, see the Apache
>> Commons CSV website:
>> 
>> http://commons.apache.org/proper/commons-csv/
>> 
>> Best regards,
>> Bruno P. Kinoshita
>> on behalf of the Apache Commons community
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ANNOUNCE] Apache Commons CSV 1.5 has been released

[Gary Gregory]

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 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 types.
> >>
> >> Source and binary distributions are available for download from the
> Apache
> >> Commons download site:
> >> http://commons.apache.org/proper/commons-csv/download_csv.cgi
> >>
> >> When downloading, please verify signatures using the KEYS file
> available at the
> >> above location.
> >>
> >> Alternatively the release can be pulled via maven:
> >> 
> >> org.apache.commons
> >> commons-csv
> >> 1.5
> >> 
> >>
> >> The release notes can be viewed at:
> >> http://www.apache.org/dist/commons/csv/RELEASE-NOTES.txt
> >>
> >> For complete information on Commons CSV, including instructions on how
> to
> >> submit bug reports, patches, or suggestions for improvement, see the
> Apache
> >> Commons CSV website:
> >>
> >> http://commons.apache.org/proper/commons-csv/
> >>
> >> Best regards,
> >> Bruno P. Kinoshita
> >> on behalf of the Apache Commons community
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [JCS] missing 2.2 release in jira?

[Thomas Vandahl]

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.

Bye, Thomas.



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] update to Log4j 2 facade API

[Matt Sicker]

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" essentially across all my libraries and in house code. I understand
that some libraries are old and stuck to commons-logging as it was the main
facade at the time (e.g., in Spring Framework), but chances are that
nowadays, at least one or more of your libraries are going to bring in
log4j-api or slf4j-api anyways.

On 3 September 2017 at 14:22, Romain Manni-Bucau 
wrote:

> 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 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-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Matt Sicker 

Re: [JCS] update to Log4j 2 facade API

[Ralph Goers]

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 a few types of users:
1. Users that have multiple apps running in the container and want them all to 
use the same configuration and log to the same files.
2. Users that have multiple apps running in the container and want them to have 
separate logging and log to different files.
3. Users that have multiple apps running in the container and want all the 
container logs and application logs to use the same configuration. 

In addition, we know that various libraries and frameworks have chosen to use 
different logging frameworks. Usually, users want all of these consolidated so 
that they can use a single configuration for the application.  This is easily 
doable except when the frameworks use java.util.logging AND the container also 
uses java.util.logging. Due to the way java.util.logging works the logging 
framework jars have to be placed in the class path of the container which makes 
it impossible to achieve item 2 above. Similarly, if the container uses ANY of 
the common logging libraries, and they are exposed on the application’s class 
path then users are required to use the logging libraries provided by the 
container and cannot use their own versions. 

That statement made in one of the emails that if JCS switches logging 
frameworks it would mean it would have to be dropped from TomEE since TomEE 
will be using JUL. This is a prime example of what I mentioned in the previous 
paragraph. The correct solution here is to get TomEE’s use of JCS out of the 
user’s application class path. Unfortunately, that isn’t trivial.

However, containers are a special case. Most frameworks just use a logging 
framework and aren’t creating their own class loaders. In that case my advice 
is always “NEVER use java.util.logging”. First, its performance is terrible and 
second it is extremely difficult to use it as an API and direct the calls to 
another framework. I have been told the implementers of jul spoke with Ceki 
before implementing it but they must not have asked him the correct questions 
to come up with a design that is so bad.

So just saying that Log4j 2 or SLF4J (or whatever else) should always be used 
isn’t necessarily correct. In the case of Tomcat or TomEE, if they cannot 
completely hide the logging framework from applications then it needs to use 
its own custom facade that any logging framework can implement (and NOT use 
JUL). What they have done with JULI was on the right track but still uses the 
java.util.logging design, which makes it very difficult for users to achieve 
item 3 above. 

As far as I can tell JCS is a general purpose caching system meant to be used 
as a library within an application. For that use case, in my opinion using the 
Log4j 2 API is a much better choice than using Commons Logging.


Ralph



> On Sep 3, 2017, at 2:09 PM, Matt Sicker  wrote:
> 
> 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" essentially across all my libraries and in house code. I understand
> that some libraries are old and stuck to commons-logging as it was the main
> facade at the time (e.g., in Spring Framework), but chances are that
> nowadays, at least one or more of your libraries are going to bring in
> log4j-api or slf4j-api anyways.
> 
> On 3 September 2017 at 14:22, Romain Manni-Bucau 
> wrote:
> 
>> 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 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-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> 
> 
> -- 
> Matt Sicker 



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] update to Log4j 2 facade API

[Romain Manni-Bucau]

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 targetting
this goal then it has been sl4j and now log4j2? Means each time you upgrade
you switch the lib which sounds horrible for a commons project.

Side note on tomee isolating jcs: compared to other servers tomee doesnt do
it to let users inherit from all features and integrate with the libs
naturally. It has the drawback you mention bit the advantage to be able to
use the full ecosystem so will likely not change soon.

Le 4 sept. 2017 02:30, "Ralph Goers"  a écrit :

> 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 a few types of users:
> 1. Users that have multiple apps running in the container and want them
> all to use the same configuration and log to the same files.
> 2. Users that have multiple apps running in the container and want them to
> have separate logging and log to different files.
> 3. Users that have multiple apps running in the container and want all the
> container logs and application logs to use the same configuration.
>
> In addition, we know that various libraries and frameworks have chosen to
> use different logging frameworks. Usually, users want all of these
> consolidated so that they can use a single configuration for the
> application.  This is easily doable except when the frameworks use
> java.util.logging AND the container also uses java.util.logging. Due to the
> way java.util.logging works the logging framework jars have to be placed in
> the class path of the container which makes it impossible to achieve item 2
> above. Similarly, if the container uses ANY of the common logging
> libraries, and they are exposed on the application’s class path then users
> are required to use the logging libraries provided by the container and
> cannot use their own versions.
>
> That statement made in one of the emails that if JCS switches logging
> frameworks it would mean it would have to be dropped from TomEE since TomEE
> will be using JUL. This is a prime example of what I mentioned in the
> previous paragraph. The correct solution here is to get TomEE’s use of JCS
> out of the user’s application class path. Unfortunately, that isn’t trivial.
>
> However, containers are a special case. Most frameworks just use a logging
> framework and aren’t creating their own class loaders. In that case my
> advice is always “NEVER use java.util.logging”. First, its performance is
> terrible and second it is extremely difficult to use it as an API and
> direct the calls to another framework. I have been told the implementers of
> jul spoke with Ceki before implementing it but they must not have asked him
> the correct questions to come up with a design that is so bad.
>
> So just saying that Log4j 2 or SLF4J (or whatever else) should always be
> used isn’t necessarily correct. In the case of Tomcat or TomEE, if they
> cannot completely hide the logging framework from applications then it
> needs to use its own custom facade that any logging framework can implement
> (and NOT use JUL). What they have done with JULI was on the right track but
> still uses the java.util.logging design, which makes it very difficult for
> users to achieve item 3 above.
>
> As far as I can tell JCS is a general purpose caching system meant to be
> used as a library within an application. For that use case, in my opinion
> using the Log4j 2 API is a much better choice than using Commons Logging.
>
>
> Ralph
>
>
>
> > On Sep 3, 2017, at 2:09 PM, Matt Sicker  wrote:
> >
> > 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" essentially across all my libraries and in house code. I
> understand
> > that some libraries are old and stuck to commons-logging as it was the
> main
> > facade at the time (e.g., in Spring Framework), but chances are that
> > nowadays, at least one or more of your libraries are going to bring in
> > log4j-api or slf4j-api anyways.
> >
> > On 3 September 2017 at 14:22, Romain Manni-Bucau 
> > wrote:
> >
> >> 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 :
> >>
>

Re: [JCS] missing 2.2 release in jira?

[Romain Manni-Bucau]

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 the "snapshot" without issues)


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-09-03 22:19 GMT+02:00 Thomas Vandahl :

> 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.
>
> Bye, Thomas.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>