Is that information being extracted from the stack frames for the function call? If so, there was a similar problem with an earlier version of SL4J where they printed the wrong calling function. I posted a bug about that one and they fixed it. I'm not sure if this is similar, but maybe we should check for a newer version of SLF4J.

I've upgraded to SFL4J 1.2 and this doesn't seem to be a problem any more. Can you confirm and close the issue if you don't see the problem? Thanks.

Just tried SLF4J 1.2 and i'm still seeing the same behaviour:
12:22:16,913 INFO [QFJ Timer] quickfixj.msg.outgoing (SLF4JLog.java:90) - FIX.4.2:MRKTC-OMS->MRKTC-EXCH: 8=FIX.4.29=6235=034=549=MRKTC-OMS52=20070211-20:22:16.90556=MRKTC-EXCH10=065

I'll play around with it some more to make sure that i'm not missing something though.

OK, I misunderstood what you wanted. I thought SLF4J was putting one of it's own file names in the log message but I see now that's the QFJ SL4JLog.java file. I haven't seen any capability in SLF4J like you've described, but I haven't looked closely for it. If you find a feature like that in SLF4J, it's fine to add it into the logger. However, remember that it's very expensive to be logging the file name and/or calling class. I know for the calling class they were creating a new Throwable for each logged line so they could process the stack trace. This isn't a QFJ issue per se, but a potential performance issue to remember at the application level.

Any more info on this issue?

sorry, haven't had time to look into this yet. I think you are right - if the functionality i'm looking for doesn't come "for free" by calling into some wrapper, it may be too expensive to create an exception to get to teh stack trace every time.

i'll look into this next week.

This seems to be related to SLF4J bug 23: http://bugzilla.slf4j.org/show_bug.cgi?id=23
It doesn't look like switching to the latest 1.3.0 version makes any difference, so i'll find out if additional work needs to be done to SLF4J to make the LocationAwareLogger work with LOG4J as well, for example.

I cross-posted this on the SLF4J list/bugzilla, and Ceki Gulku suggested an approach to get it work in http://bugzilla.slf4j.org/show_bug.cgi?id=44#c1

Essentially, there's a "LocationAwareLogger" interface in SLF4J, so we need to check if that's what we get back and call through to the function that takes in a location wrapper.

Will work on getting that to work. don't think that it'll add extra overhead, but will need to see how underlying Log4j implementation handles it.

Fixed in checkin 612. SLF4JLog now distinguishes between a regular and a LocationAwareLogger.