Incorrect file name and line number

[wafisher]

For my logback.xml configuration of:

<pattern>... \(%F:%L\) %msg%n</pattern>

I'm consistently getting file name / line number in the KLogger file (KLogger.kt:23) for all my debug statements, which is precisely where KLogger itself calls debug().

I'm using 1.4.2 so #11 shouldn't apply. This happens when I use val logger = LoggerFactory.getLogger("class name") or private val logger = KotlinLogging.logger {}.

Thanks!

[oshai]

Can you please share a repo that reproduces it?

[oshai]

And another question - when you use slf4j directly do you get correct location? If not it's probably a configuration issue.

[wafisher]

Yes, the location is definitely right when using LOG from slf4j.

Our codebase is not open source so it's a little hard to point you at something. Is there any idea you might have that would help me debug it? It does seem to be using a LocationAware version of the logger.

[wafisher]

I'm getting the following with %caller:

Caller+0	 at mu.KLogger$DefaultImpls.info(KLogger.kt:30)
Caller+1	 at mu.internal.LocationAwareKLogger.info(LocationAwareKLogger.kt:13)
Caller+2	 at com.bowerylabs.position.ml.MainKt.main(Main.kt:37)
Caller+3	 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

And then %F:%L will be KLogger.kt:30 which is not what I care about. I want to see Main.kt:37. Is that possible? I understand why it does this since the real call to info is, indeed, at line 30 of KLogger.kt

[oshai]

Here is what I suspect: LocationAwareKLogger has a field called fqcn which is the name of the class LocationAwareKLogger. I think that it is because some methods has default implementation in 'KLogger' which was not overriden in LocationAwareKLogger. it is solvable by just overriding all the methods. I will add a test to check that, but you can as well try to call a method like logger.info("test") [not the lambda flavour].

[wafisher]

Just tested and you're right, the non-lambda flavor works perfectly!

[oshai]

that is what I suspected - I will create a fix for it and release 1.4.3

[oshai]

I wasnt able to reproduce it - I think because it doesnt happen with log4j implementation. anyway I will release 1.4.3 and we will make sure it fix the issue.

[wafisher]

Great thank you for the quick turnaround.

[oshai]

1.4.3 is deployed. let me know if it was solved.

[wafisher]

Fixes it for me.