[DISCUSS] Logging

[Mark Thomas <ma...@apache.org>]

I've been looking at Bug 58588 [1]. It looks clear that the JULI extras
JARs no longer add value and I'm happy to remove them. That bug also
raises the question "How would users switch Tomcat's internal logging to
LOGBack, log4j2 or something else?".

A quick look at the respective manuals suggest the following:

LOGBack inserts itself via the root logger so that should be OK. In this
case we'd have:

Tomcat -> JULI -> JUL -> LOGBack

log4j2 replaces the LogManager. Providing a suitable selector (class
loader or JNDI was used) this should be fine. In this case we'd have:

Tomcat -> JULI -> log4j2

Thinking about all of this got me wondering. A primary driver for JULI
was the lack of class loader aware logging frameworks. This particular
problem appears to be solved (at least log4j and logback have solved
it). Do we want to consider a change to the logging framework? Possible
options include:

1. Simplified JULI that uses JUL directly but with our existing
LogManager and configuration extensions.

2. Native log4j2.

3. Use SLF4j API with log4j2 by default.

4. Use SLF4j API with logback by default.

5. Something else...

6. Do nothing.

Currently, I'm leaning towards either doing nothing (what we have works)
or option 1. Options 2-5 all involved adding additional libraries which
I instinctively prefer not to do without a really good reason.

Thoughts?


[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=58588

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: [DISCUSS] Logging

[Mark Thomas <ma...@apache.org>]

On 25/05/2016 12:26, R�my Maucherat wrote:
> 2016-05-25 12:43 GMT+02:00 Mark Thomas <ma...@apache.org>:
> 
>> I've been looking at Bug 58588 [1]. It looks clear that the JULI extras
>> JARs no longer add value and I'm happy to remove them. That bug also
>> raises the question "How would users switch Tomcat's internal logging to
>> LOGBack, log4j2 or something else?".
>>
>> A quick look at the respective manuals suggest the following:
>>
>> LOGBack inserts itself via the root logger so that should be OK. In this
>> case we'd have:
>>
>> Tomcat -> JULI -> JUL -> LOGBack
>>
>> log4j2 replaces the LogManager. Providing a suitable selector (class
>> loader or JNDI was used) this should be fine. In this case we'd have:
>>
>> Tomcat -> JULI -> log4j2
>>
>> Thinking about all of this got me wondering. A primary driver for JULI
>> was the lack of class loader aware logging frameworks. This particular
>> problem appears to be solved (at least log4j and logback have solved
>> it). Do we want to consider a change to the logging framework? Possible
>> options include:
>>
>> 1. Simplified JULI that uses JUL directly but with our existing
>> LogManager and configuration extensions.
>>
>> 2. Native log4j2.
>>
>> 3. Use SLF4j API with log4j2 by default.
>>
>> 4. Use SLF4j API with logback by default.
>>
>> 5. Something else...
>>
>> 6. Do nothing.
>>
>> Currently, I'm leaning towards either doing nothing (what we have works)
>> or option 1. Options 2-5 all involved adding additional libraries which
>> I instinctively prefer not to do without a really good reason.
>>
>> Thoughts?
>>
> 
> I'd vote 6. Switching is a lot of trouble with little benefit.
> What would be the changes for 1 exactly ? The thing is/was supposed to be
> simple already.

When I wrote the original e-mail I wasn't sure. All I had in my mind was
that Tomcat -> j.u.l. should be simpler than Tomcat -> CL -> j.u.l.

I've taken a quick look and what this means in terms of code is:
- We could remove o.a.juli.logging. All 92 lines of code.
- A huge amount of renaming (see the sample diff attached)

In terms of performance, the current CL layer always triggers an
exception to determine the current class and method. With direct to
j.u.l. it should be possible to avoid this if those values are not
required in the output. That could significantly speed up logging.
However, Tomcat doesn't log much unless it really has to so the real
performance benefit is probably minimal. And in debug situations, the
class and method can be very helpful.

To be sure of the performance impact, we'd need to try it. The changes
look to be fairly easy to do via global search and replace so I'll give
it a go locally and see what happens.

Mark

Re: [DISCUSS] Logging

[Mark Thomas <ma...@apache.org>]

On 25/05/2016 15:03, Mark Thomas wrote:
> On 25/05/2016 12:26, R�my Maucherat wrote:
>> 2016-05-25 12:43 GMT+02:00 Mark Thomas <ma...@apache.org>:

<snip/>

>>> 1. Simplified JULI that uses JUL directly but with our existing
>>> LogManager and configuration extensions.

<snip/>

>>> Thoughts?
>>>
>>
>> I'd vote 6. Switching is a lot of trouble with little benefit.
>> What would be the changes for 1 exactly ? The thing is/was supposed to be
>> simple already.

<snip/>

> To be sure of the performance impact, we'd need to try it. I took a
> quick look at this and it isn't quite as simple as a global search and
> replace. I've set up a local branch where I can try this. I'll see how
> much work it turns out to be.

It is 2-3 hours of effort to switch all the Tomcat code to go directly
to j.u.l. There is a fair amount of automated conversion so some further
manual clean-up is likely to be required.

Pros:
- No need for JARs to depend on JULI. In theory this makes it easier for
  other folks to consume things like Jasper or Tomcat JDBC.
- JULI becomes a 'drop-in' extension to j.u.l. that folks can use
  without having to change any existing code

Cons:
- It breaks multiple APIs. We pass Log instances in quite a few places.
- Minimal performance difference. I ran the same test 5 times with no
  clear performance difference. If there is one, it is going to be
  small.
- It is likely to cause merge errors for back-ports.
- The code isn't as clean as the Logger API does not support
  log.<level>(String, Throwable)

Overall, I think this was an interesting experiment but it is not worth
it for the majority of the code.

If there is demand from down-stream consumers of components like Jasper
or WebSocket to remove the JULI dependency then we can look at that on a
case by case basis.

I'll keep the branch locally for now in case it is useful.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: [DISCUSS] Logging

[Mark Thomas <ma...@apache.org>]

On 25/05/2016 12:26, R�my Maucherat wrote:
> 2016-05-25 12:43 GMT+02:00 Mark Thomas <ma...@apache.org>:
> 
>> I've been looking at Bug 58588 [1]. It looks clear that the JULI extras
>> JARs no longer add value and I'm happy to remove them. That bug also
>> raises the question "How would users switch Tomcat's internal logging to
>> LOGBack, log4j2 or something else?".
>>
>> A quick look at the respective manuals suggest the following:
>>
>> LOGBack inserts itself via the root logger so that should be OK. In this
>> case we'd have:
>>
>> Tomcat -> JULI -> JUL -> LOGBack
>>
>> log4j2 replaces the LogManager. Providing a suitable selector (class
>> loader or JNDI was used) this should be fine. In this case we'd have:
>>
>> Tomcat -> JULI -> log4j2
>>
>> Thinking about all of this got me wondering. A primary driver for JULI
>> was the lack of class loader aware logging frameworks. This particular
>> problem appears to be solved (at least log4j and logback have solved
>> it). Do we want to consider a change to the logging framework? Possible
>> options include:
>>
>> 1. Simplified JULI that uses JUL directly but with our existing
>> LogManager and configuration extensions.
>>
>> 2. Native log4j2.
>>
>> 3. Use SLF4j API with log4j2 by default.
>>
>> 4. Use SLF4j API with logback by default.
>>
>> 5. Something else...
>>
>> 6. Do nothing.
>>
>> Currently, I'm leaning towards either doing nothing (what we have works)
>> or option 1. Options 2-5 all involved adding additional libraries which
>> I instinctively prefer not to do without a really good reason.
>>
>> Thoughts?
>>
> 
> I'd vote 6. Switching is a lot of trouble with little benefit.
> What would be the changes for 1 exactly ? The thing is/was supposed to be
> simple already.

When I wrote the original e-mail I wasn't sure. All I had in my mind was
that Tomcat -> j.u.l. should be simpler than Tomcat -> CL -> j.u.l.

I've taken a quick look and what this means in terms of code is:
- We could remove o.a.juli.logging. All 92 lines of code.
- A huge amount of renaming

In terms of performance, the current CL layer always triggers an
exception to determine the current class and method. With direct to
j.u.l. it should be possible to avoid this if those values are not
required in the output. That could significantly speed up logging.
However, Tomcat doesn't log much unless it really has to so the real
performance benefit is probably minimal. And in debug situations, the
class and method can be very helpful.

To be sure of the performance impact, we'd need to try it. I took a
quick look at this and it isn't quite as simple as a global search and
replace. I've set up a local branch where I can try this. I'll see how
much work it turns out to be.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: [DISCUSS] Logging

[Rémy Maucherat <re...@apache.org>]

2016-05-25 12:43 GMT+02:00 Mark Thomas <ma...@apache.org>:

> I've been looking at Bug 58588 [1]. It looks clear that the JULI extras
> JARs no longer add value and I'm happy to remove them. That bug also
> raises the question "How would users switch Tomcat's internal logging to
> LOGBack, log4j2 or something else?".
>
> A quick look at the respective manuals suggest the following:
>
> LOGBack inserts itself via the root logger so that should be OK. In this
> case we'd have:
>
> Tomcat -> JULI -> JUL -> LOGBack
>
> log4j2 replaces the LogManager. Providing a suitable selector (class
> loader or JNDI was used) this should be fine. In this case we'd have:
>
> Tomcat -> JULI -> log4j2
>
> Thinking about all of this got me wondering. A primary driver for JULI
> was the lack of class loader aware logging frameworks. This particular
> problem appears to be solved (at least log4j and logback have solved
> it). Do we want to consider a change to the logging framework? Possible
> options include:
>
> 1. Simplified JULI that uses JUL directly but with our existing
> LogManager and configuration extensions.
>
> 2. Native log4j2.
>
> 3. Use SLF4j API with log4j2 by default.
>
> 4. Use SLF4j API with logback by default.
>
> 5. Something else...
>
> 6. Do nothing.
>
> Currently, I'm leaning towards either doing nothing (what we have works)
> or option 1. Options 2-5 all involved adding additional libraries which
> I instinctively prefer not to do without a really good reason.
>
> Thoughts?
>

I'd vote 6. Switching is a lot of trouble with little benefit.
What would be the changes for 1 exactly ? The thing is/was supposed to be
simple already.

At JBoss, they use a logging tool with strong typing and a preprocessing
tool. I was initially skeptical, but it worked well after a while. The
extra robustness is nice in a way, it gives a bit more.

Rémy