[JCS] update to Log4j 2 facade API

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[JCS] update to Log4j 2 facade API

garydgregory
Hi All,

How about updating JCS from Commons Logging to Log4j 2?

Gary
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

Romain Manni-Bucau
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 <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-09-02 19:55 GMT+02:00 Gary Gregory <[hidden email]>:

> Hi All,
>
> How about updating JCS from Commons Logging to Log4j 2?
>
> Gary
>
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

Matt Sicker
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.

On 2 September 2017 at 13:04, Romain Manni-Bucau <[hidden email]>
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 <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-09-02 19:55 GMT+02:00 Gary Gregory <[hidden email]>:
>
> > Hi All,
> >
> > How about updating JCS from Commons Logging to Log4j 2?
> >
> > Gary
> >
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

Romain Manni-Bucau
Le 2 sept. 2017 22:34, "Matt Sicker" <[hidden email]> 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 <[hidden email]>
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 <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-09-02 19:55 GMT+02:00 Gary Gregory <[hidden email]>:
>
> > Hi All,
> >
> > How about updating JCS from Commons Logging to Log4j 2?
> >
> > Gary
> >
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

Thomas Vandahl
In reply to this post by Romain Manni-Bucau
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

Thomas Vandahl
In reply to this post by Romain Manni-Bucau
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

garydgregory
On Sep 3, 2017 12:00, "Thomas Vandahl" <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:

> On Sep 3, 2017 12:00, "Thomas Vandahl" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

Romain Manni-Bucau
In reply to this post by garydgregory
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" <[hidden email]> a écrit :

On Sep 3, 2017 12:00, "Thomas Vandahl" <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

Thomas Vandahl
In reply to this post by garydgregory
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

Thomas Vandahl
In reply to this post by Romain Manni-Bucau
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

garydgregory
In reply to this post by Thomas Vandahl
On Sun, Sep 3, 2017 at 12:12 PM, Thomas Vandahl <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

Romain Manni-Bucau
In reply to this post by Thomas Vandahl
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" <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]>
> 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" <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
>
> --
> Matt Sicker <[hidden email]>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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" <[hidden email]> 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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> >
> >
> > --
> > Matt Sicker <[hidden email]>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

Matt Sicker
You don't duplicate any logging config. You can use both slf4j-api and
log4j-api with either logback or log4j2.

On 4 September 2017 at 00:08, Romain Manni-Bucau <[hidden email]>
wrote:

> 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" <[hidden email]> 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 <[hidden email]> 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 <
> [hidden email]>
> > > 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" <[hidden email]> 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: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >
> > >
> > >
> > > --
> > > Matt Sicker <[hidden email]>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

Romain Manni-Bucau
Le 4 sept. 2017 20:44, "Matt Sicker" <[hidden email]> a écrit :

You don't duplicate any logging config. You can use both slf4j-api and
log4j-api with either logback or log4j2.


Except you dont always have the choice with 2 apis. It also messes up
logging lifecycle and setup which needs 2 integrations in the environment.
Whatever reason you use it is not free to switch and even if log4j2 is
awesome, it is far to be a first citizen api for a common library used in a
lot of contexts IMHO.



On 4 September 2017 at 00:08, Romain Manni-Bucau <[hidden email]>
wrote:

> 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" <[hidden email]> 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 <[hidden email]> 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 <
> [hidden email]>
> > > 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" <[hidden email]> 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: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >
> > >
> > >
> > > --
> > > Matt Sicker <[hidden email]>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

Ralph Goers

> On Sep 4, 2017, at 2:24 PM, Romain Manni-Bucau <[hidden email]> wrote:
>
> Le 4 sept. 2017 20:44, "Matt Sicker" <[hidden email]> a écrit :
>
> You don't duplicate any logging config. You can use both slf4j-api and
> log4j-api with either logback or log4j2.
>
>
> Except you dont always have the choice with 2 apis. It also messes up
> logging lifecycle and setup which needs 2 integrations in the environment.
> Whatever reason you use it is not free to switch and even if log4j2 is
> awesome, it is far to be a first citizen api for a common library used in a
> lot of contexts IMHO.

Now you have me curious about your last sentence. In you opinion, what is keeping Log4j2 from being a first citizen api for a common library? You didn’t mention SLF4J in that sentence so I am assuming you consider it to be one. Why?

Ralph

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [JCS] update to Log4j 2 facade API

Romain Manni-Bucau
Le 5 sept. 2017 05:40, "Ralph Goers" <[hidden email]> a écrit :


> On Sep 4, 2017, at 2:24 PM, Romain Manni-Bucau <[hidden email]>
wrote:

>
> Le 4 sept. 2017 20:44, "Matt Sicker" <[hidden email]> a écrit :
>
> You don't duplicate any logging config. You can use both slf4j-api and
> log4j-api with either logback or log4j2.
>
>
> Except you dont always have the choice with 2 apis. It also messes up
> logging lifecycle and setup which needs 2 integrations in the environment.
> Whatever reason you use it is not free to switch and even if log4j2 is
> awesome, it is far to be a first citizen api for a common library used in
a
> lot of contexts IMHO.

Now you have me curious about your last sentence. In you opinion, what is
keeping Log4j2 from being a first citizen api for a common library? You
didn’t mention SLF4J in that sentence so I am assuming you consider it to
be one. Why?


Purely usages as an api. Once again the fact I'm very cautious moving to
log4j2 api is not about the quality of log4j2. Take most of asf project
stacks and I guess slf4j, jul or even commons logging will be more used
than log4j2 as an API. Side question: wonder if we can extract this stat
through asf infra?

I hear the "if noone starts" side of the issue but it must be more global
than just one lib by lib (a bit like when tomee needs to support one more
java version and upgrades asm in openjpa, cxf, tomee, owb, ... at once).



Ralph

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
12