Bug 47014 - Method Name in log (%M) invalid for some callers when using Category.log(...)
Summary: Method Name in log (%M) invalid for some callers when using Category.log(...)
Status: RESOLVED DUPLICATE of bug 44888
Alias: None
Product: Log4j - Now in Jira
Classification: Unclassified
Component: Other (show other bugs)
Version: 1.2
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: log4j-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-10 11:54 UTC by larae77
Modified: 2009-10-10 12:41 UTC (History)
0 users


Attachments
Bundled Maven project with unit tests that demonstrat issue in console (1.34 KB, application/gzip)
2009-04-10 11:54 UTC, larae77 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description larae77 2009-04-10 11:54:06 UTC 
Created attachment 23479 [details]
Bundled Maven project with unit tests that demonstrat issue in console

Overview: 
The method name returned by %M can be invalid when using the following method:

Category.log(String callerFQCN, Priority level, Object message, Throwable t);

From a class that has a fully qualified name that is a substring of the log4j.Logger's category.


Additional Information: 

Attached maven project demonstrates scenario, prints messages to console.

Proposed Fix:
Add "." to end fqnOfCallingClass in LocationInfo before searching stacktrace for method.
Comment 1 Jacob Kjome 2009-04-10 20:45:02 UTC 
Adding a period at the end of the FQCN is the recommended way for wrapper classes to call logger.log(), though I'm not sure read that information (a long while back).  I'm not sure I see this as a bug in Log4j code, but in documentation?
Comment 2 Curt Arnold 2009-05-03 14:28:20 UTC 
Could you check this against the current SVN HEAD?  I believe this has been fixed, but can't find the bug report at the moment.
Comment 3 Curt Arnold 2009-10-10 12:41:16 UTC 
Underlining issue was addressed in bug 44888 committed 2008-05-19.  Other changes to LocationInfo also address the issue.  It does however break the work around of appending a trailing "." to the fully qualified file name.

*** This bug has been marked as a duplicate of bug 44888 ***