KLogger obscures location info

[dhutchis]

I am using log4j with a patternlayout that includes class, method, and line number information. I expect log statements to print in the form below. This form holds when I manually set val logger: Logger = LoggerFactory.getLogger(this.javaClass).

INFO TEST_CONFIG.<init>(80) - test log

Instead, when I extend a companion object (or any singleton object) with object : KLogging(), the following unhelpful information prints

INFO KLogger.info(?) - test log

The code responsible for picking the location info is here in LocationInfo. The code sees that KLogger is the immediately logging class on the stack trace and uses KLogger for location info. It should instead use the class immediately below KLogger in the stack trace.

I'm not sure how to fix it, but there should be some hook in the log4j (ideally, slf4j) library that allows manipulating location info.

[dhutchis]

I see where the endpoint logging class is set in slf4j: Log4JLoggerAdapter. It seems that changing the FQCN there would be difficult while staying agnostic to the particular logging framework.

For now I will opt to handle logging without the KLogging library. Good idea though-- the library came very close to achieving a standardized elegance in Kotlin logging.

[oshai]

Thanks for raising the issue and the detailed explanation. I will try to
find a solution for that.

On Oct 12, 2016 1:26 AM, "Dylan Hutchison" [email protected] wrote:

I see where the endpoint logging class is set in slf4j: Log4JLoggerAdapter
https://github.com/qos-ch/slf4j/blob/master/slf4j-log4j12/src/main/java/org/slf4j/impl/Log4jLoggerAdapter.java#L70.
It seems that changing the FQCN there would be difficult while staying
agnostic to the particular logging framework.

For now I will opt to handle logging without the KLogging library. Good
idea though-- the library came very close to achieving a standardized
elegance in Kotlin logging.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#11 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACj0QXDWz96gr_UOH_EAgf8i_8eb8841ks5qzA0AgaJpZM4KUKLT
.

[oshai]

I think I might be able to solve that. Do you have any test or small
project that you can share and reproduce the issue?

On Oct 12, 2016 8:08 AM, "ohad shai" [email protected] wrote:

Thanks for raising the issue and the detailed explanation. I will try to
find a solution for that.

On Oct 12, 2016 1:26 AM, "Dylan Hutchison" [email protected]
wrote:

I see where the endpoint logging class is set in slf4j:
Log4JLoggerAdapter
https://github.com/qos-ch/slf4j/blob/master/slf4j-log4j12/src/main/java/org/slf4j/impl/Log4jLoggerAdapter.java#L70.
It seems that changing the FQCN there would be difficult while staying
agnostic to the particular logging framework.

For now I will opt to handle logging without the KLogging library. Good
idea though-- the library came very close to achieving a standardized
elegance in Kotlin logging.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#11 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACj0QXDWz96gr_UOH_EAgf8i_8eb8841ks5qzA0AgaJpZM4KUKLT
.

[dhutchis]

Sorry, I don't have a small project handy at the moment. It should be easy to recreate. Any project that uses slf4j-log4j will run into it. Here's a log4j.xml you can use

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/xml/doc-files/log4j.dtd">
<log4j:configuration>
  <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
    <layout class="org.apache.log4j.PatternLayout">
      <param name="ConversionPattern"
             value="%d{ISO8601} %p %C{1}.%M(%L) - %m%n"/>
    </layout>
  </appender>

  <root>
    <level value="INFO"/>
    <appender-ref ref="CONSOLE"/>
  </root>

</log4j:configuration>

[oshai]

a possible solution is to do something similar to: https://github.com/qos-ch/slf4j/blob/master/slf4j-ext/src/main/java/org/slf4j/ext/LoggerWrapper.java
con's are: methods can't be inlined and all logger interface methods has to be delegated explicitly as opposed to current implementation that delegation is implicit.
inline methods might have advantage on android. see issue #1. a possible solution for that is to have two KLogger flavours with a configuration to select which one to use, but this sounds like interface clutter.

[dhutchis]

Inlining is fine when the inline functions are extension methods on the
slf4j Logger. That's the solution I am currently using.

On Oct 14, 2016 5:18 AM, "oshai" [email protected] wrote:

a possible solution is to do something similar to:
https://github.com/qos-ch/slf4j/blob/master/slf4j-ext/
src/main/java/org/slf4j/ext/LoggerWrapper.java
con's are: methods can't be inlined and all logger interface methods has
to be delegated explicitly as opposed to current implementation that
delegation is implicit.
inline methods might have advantage on android. see issue #1
#1. a possible
solution for that is to have two KLogger flavours with a configuration to
select which one to use, but this sounds like interface clutter.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#11 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABm-diacwhRviO-DzZahmX1zzl_7pZyfks5qz3L0gaJpZM4KUKLT
.

[oshai]

couple of notes:

• from my checks inlined methods do not have line number information. If you can share a different example it will be great.
• extension methods are a poor solution for that case in my experience: requires imports which are sometimes not obvious to users.

[oshai]

fixed in 1.4

[dhutchis]

Nice job! The inline function logging retained information for me, for some reason. Maybe the Kotlin compiler chose not to inline the functions marked inline. It makes sense that that information would be lost.