http://bugzilla.slf4j.org/show_bug.cgi?id=13
------- Additional Comments From [EMAIL PROTECTED] 2006-02-06 14:44 ------- Although I am happy about your +0 vote as it clears an obstacle, I would like to make sure that the pros and cons of the issue are properly understood by everyone so that Boris will not later regret his +0 vote. It seems to me that we have established that Peter's patch will not impact users of vanilla JDK logging because each of the formatters that ship with the JDK cause caller information to be inferred for every log call. Peter's patch displaces the time when the cost of inferring the caller is paid, but not the fact that is paid. However, with PatternFormatter which ships with x4juli, inferring caller information depends on the pattern specified by the user. Now, with Peter's patch to JDK14LoggerAdapter caller information will be inferred for every log call. The fact that x4juli's PatternFormatter does *not* always infer caller information would become irrelevant because the patched JDK14LoggerAdapter would compute caller information before x4juli code is exercised. Boris writes: > For x4juli there is no problem, neither whith or without the > patch. x4juli generates LocationInformation just and only when the > user configures the Formatter to do so. (Ceki: You will remember that > feature, think of PatternLayout :-) How does the patch *not* impact the generation of caller information in the x4juli case? As I understand it, there would be an impact. Peter's patch would cause caller information to be generation for every log call regardless of what PatternFormatter's lazy caller inferring. My proposal is to apply Peter's patch to JDK14LoggerAdapter for use with SLF4J's binding for vanilla JDK logging but *not* for x4juli. X4juli should have its own copy of JDK14LoggerAdapter. Does the above make sense? Sound reasonable? -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. _______________________________________________ dev mailing list [email protected] http://slf4j.org/mailman/listinfo/dev
