You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2017/04/15 21:32:10 UTC
Re: TC 8.5 and Log4J2 via Juli: Wrong location info
Coming back to this.
Reminder:
- in TC 8.5 we removed explicit support for Log4J(2)
- we direct users at the Log4J2 JUL bridge
- the Log4J2 JUL bridge works by adding the additional Log4J2 jar files
to the CLASSPATH and setting LOGGING_MANAGER to
-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager
Now there's a problem: the log4j2 implementation of retrieving location
info (e.g. %C, %l, %F, %L) from the stack isn't aware of our juli
sitting between the real jul classes and log4J2 and so always results in
org.apache.juli.logging.DirectJDKLog as location of the log event
instead of the real class containing the log statement.
Of course location info patterns are not recommended for performance
reasons, nevertheless I think they should work correctly for debugging
purposes.
One suggested solution was:
- add a org.apache.juli.logging.Log impl that delegates to Log4J2
(instead of the JUL bridge)
and
- add a Log4jLogEventFactory that additionally skips our DirectJDKLog
when looking for the location info in the stack.
I implemented this. See the patch for 8.5 at
http://home.apache.org/~rjung/patches/tc8.5.x-juli-log4j2.patch
The way I did it, is adding back a tomcat-juli-adapters.jar, which
contains the above two classes. Adding this instead of the Log4J2 JUL
bridge to the CLASSPATH (plus the Log4J2 api and core jars, but no
changes to LOGGING_MANAGER) result in Log4J2 being used and logging with
correct location info.
Would that make a useful addition for TC 8.5 (and 9)?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TC 8.5 and Log4J2 via Juli: Wrong location info
Posted by Mark Thomas <ma...@apache.org>.
On 17/04/17 13:41, Rainer Jung wrote:
> Am 17.04.2017 um 11:49 schrieb R�my Maucherat:
>> 2017-04-15 23:32 GMT+02:00 Rainer Jung <ra...@kippdata.de>:
>>
>>> Coming back to this.
>>>
>>> Reminder:
>>>
>>> - in TC 8.5 we removed explicit support for Log4J(2)
>>>
>>> - we direct users at the Log4J2 JUL bridge
>>>
>>> - the Log4J2 JUL bridge works by adding the additional Log4J2 jar
>>> files to
>>> the CLASSPATH and setting LOGGING_MANAGER to
>>> -Djava.util.logging.manager=or
>>> g.apache.logging.log4j.jul.LogManager
>>>
>>> Now there's a problem: the log4j2 implementation of retrieving location
>>> info (e.g. %C, %l, %F, %L) from the stack isn't aware of our juli
>>> sitting
>>> between the real jul classes and log4J2 and so always results in
>>> org.apache.juli.logging.DirectJDKLog as location of the log event
>>> instead
>>> of the real class containing the log statement.
>>>
>>> Of course location info patterns are not recommended for performance
>>> reasons, nevertheless I think they should work correctly for debugging
>>> purposes.
>>>
>>> One suggested solution was:
>>>
>>> - add a org.apache.juli.logging.Log impl that delegates to Log4J2
>>> (instead
>>> of the JUL bridge)
>>>
>>> and
>>>
>>> - add a Log4jLogEventFactory that additionally skips our DirectJDKLog
>>> when
>>> looking for the location info in the stack.
>>>
>>> I implemented this. See the patch for 8.5 at
>>>
>>> http://home.apache.org/~rjung/patches/tc8.5.x-juli-log4j2.patch
>>>
>>> The way I did it, is adding back a tomcat-juli-adapters.jar, which
>>> contains the above two classes. Adding this instead of the Log4J2 JUL
>>> bridge to the CLASSPATH (plus the Log4J2 api and core jars, but no
>>> changes
>>> to LOGGING_MANAGER) result in Log4J2 being used and logging with correct
>>> location info.
>>>
>>> Would that make a useful addition for TC 8.5 (and 9)?
>>>
>>> Ok, so the dependency from extras to log4j is removed just to be added
>> back 5 minutes later as a real dependency. Interesting !
>> Personally, I'm probably going to vote "no".
>
> The idea here is not to remove some dependency but to fix the "wrong
> location info" problem/bug.
>
> Or do you see a new dependency creeping in here? The patch does
> introduce a compile time dependency to log4j but not a runtime
> dependency unless you are using the optional adapters jar (to fix the
> location info bug).
>
> I still do not see a better way to fix the problem.
It is a pity it looks like we'll have to re-introduce the adapter
concept to support log4j2 directly but I don't see a way around it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TC 8.5 and Log4J2 via Juli: Wrong location info
Posted by Rainer Jung <ra...@kippdata.de>.
Am 17.04.2017 um 11:49 schrieb R�my Maucherat:
> 2017-04-15 23:32 GMT+02:00 Rainer Jung <ra...@kippdata.de>:
>
>> Coming back to this.
>>
>> Reminder:
>>
>> - in TC 8.5 we removed explicit support for Log4J(2)
>>
>> - we direct users at the Log4J2 JUL bridge
>>
>> - the Log4J2 JUL bridge works by adding the additional Log4J2 jar files to
>> the CLASSPATH and setting LOGGING_MANAGER to -Djava.util.logging.manager=or
>> g.apache.logging.log4j.jul.LogManager
>>
>> Now there's a problem: the log4j2 implementation of retrieving location
>> info (e.g. %C, %l, %F, %L) from the stack isn't aware of our juli sitting
>> between the real jul classes and log4J2 and so always results in
>> org.apache.juli.logging.DirectJDKLog as location of the log event instead
>> of the real class containing the log statement.
>>
>> Of course location info patterns are not recommended for performance
>> reasons, nevertheless I think they should work correctly for debugging
>> purposes.
>>
>> One suggested solution was:
>>
>> - add a org.apache.juli.logging.Log impl that delegates to Log4J2 (instead
>> of the JUL bridge)
>>
>> and
>>
>> - add a Log4jLogEventFactory that additionally skips our DirectJDKLog when
>> looking for the location info in the stack.
>>
>> I implemented this. See the patch for 8.5 at
>>
>> http://home.apache.org/~rjung/patches/tc8.5.x-juli-log4j2.patch
>>
>> The way I did it, is adding back a tomcat-juli-adapters.jar, which
>> contains the above two classes. Adding this instead of the Log4J2 JUL
>> bridge to the CLASSPATH (plus the Log4J2 api and core jars, but no changes
>> to LOGGING_MANAGER) result in Log4J2 being used and logging with correct
>> location info.
>>
>> Would that make a useful addition for TC 8.5 (and 9)?
>>
>> Ok, so the dependency from extras to log4j is removed just to be added
> back 5 minutes later as a real dependency. Interesting !
> Personally, I'm probably going to vote "no".
The idea here is not to remove some dependency but to fix the "wrong
location info" problem/bug.
Or do you see a new dependency creeping in here? The patch does
introduce a compile time dependency to log4j but not a runtime
dependency unless you are using the optional adapters jar (to fix the
location info bug).
I still do not see a better way to fix the problem.
Or maybe I misunderstood you.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TC 8.5 and Log4J2 via Juli: Wrong location info
Posted by Rémy Maucherat <re...@apache.org>.
2017-04-15 23:32 GMT+02:00 Rainer Jung <ra...@kippdata.de>:
> Coming back to this.
>
> Reminder:
>
> - in TC 8.5 we removed explicit support for Log4J(2)
>
> - we direct users at the Log4J2 JUL bridge
>
> - the Log4J2 JUL bridge works by adding the additional Log4J2 jar files to
> the CLASSPATH and setting LOGGING_MANAGER to -Djava.util.logging.manager=or
> g.apache.logging.log4j.jul.LogManager
>
> Now there's a problem: the log4j2 implementation of retrieving location
> info (e.g. %C, %l, %F, %L) from the stack isn't aware of our juli sitting
> between the real jul classes and log4J2 and so always results in
> org.apache.juli.logging.DirectJDKLog as location of the log event instead
> of the real class containing the log statement.
>
> Of course location info patterns are not recommended for performance
> reasons, nevertheless I think they should work correctly for debugging
> purposes.
>
> One suggested solution was:
>
> - add a org.apache.juli.logging.Log impl that delegates to Log4J2 (instead
> of the JUL bridge)
>
> and
>
> - add a Log4jLogEventFactory that additionally skips our DirectJDKLog when
> looking for the location info in the stack.
>
> I implemented this. See the patch for 8.5 at
>
> http://home.apache.org/~rjung/patches/tc8.5.x-juli-log4j2.patch
>
> The way I did it, is adding back a tomcat-juli-adapters.jar, which
> contains the above two classes. Adding this instead of the Log4J2 JUL
> bridge to the CLASSPATH (plus the Log4J2 api and core jars, but no changes
> to LOGGING_MANAGER) result in Log4J2 being used and logging with correct
> location info.
>
> Would that make a useful addition for TC 8.5 (and 9)?
>
> Ok, so the dependency from extras to log4j is removed just to be added
back 5 minutes later as a real dependency. Interesting !
Personally, I'm probably going to vote "no".
Rémy