- slf4j-dev - mailman3.qos.ch

[Bug 244] New: LocationAwareLogger interface does not support the raw (unformatted) message
by bugzilla-daemon＠pixie.qos.ch 14 Sep '11

14 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=244 Summary: LocationAwareLogger interface does not support the raw (unformatted) message Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Mac OS X 10.3 Status: NEW Severity: normal Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: git(a)netcc.us LocationAwareLogger interface does not support passing of the raw (unformatted) message. As a result, I'm guessing the Logback message filter will not work as expected when using a LoggerWrapper such as XLogger. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 243] New: XLogger entry, exit, etc. do not support non LocationAwareLoggers
by bugzilla-daemon＠pixie.qos.ch 14 Sep '11

14 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=243 Summary: XLogger entry, exit, etc. do not support non LocationAwareLoggers Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Mac OS X 10.3 Status: NEW Severity: blocker Priority: P1 Component: slf4j-ext AssignedTo: slf4j-dev(a)qos.ch ReportedBy: git(a)netcc.us Calls to entry, exit, etc. are silently ignored for non LocationAwareLoggers. These methods have an outer if statement that checks for instanceofLAL without a corresponding else. For example, see: https://github.com/ceki/slf4j/blob/v_1.6.2/slf4j-ext/src/main/java/org/slf4… -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 242] New: log4j-over-slf4j silently ignores Throwables in some cases
by bugzilla-daemon＠pixie.qos.ch 14 Sep '11

14 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=242 Summary: log4j-over-slf4j silently ignores Throwables in some cases Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Mac OS X 10.3 Status: NEW Severity: blocker Priority: P1 Component: log4j-over-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: git(a)netcc.us For non LocationAwareLoggers, Throwables are silently ignored. See: https://github.com/ceki/slf4j/blob/v_1.6.2/log4j-over-slf4j/src/main/java/o… For trace(Object message, Throwable t), the Throwable is silently ignored. See: https://github.com/ceki/slf4j/blob/v_1.6.2/log4j-over-slf4j/src/main/java/o… -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

Benefits of Message objects?
by Ceki Gülcü 11 Sep '11

11 Sep '11

Hi Joern, With hindsight, could you provide a short list of benefits related to Message objects in your code? Many thanks in advance, -- Ceki

7 22

[Bug 31] Varargs for Logger methods
by bugzilla-daemon＠pixie.qos.ch 07 Sep '11

07 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #95 from Joern Huxhorn <joern(a)huxhorn.de> 2011-09-07 21:54:32 CEST --- I just sent a rather big post to the mailing list. See http://marc.info/?l=slf4j-dev&m=131542485810744&w=2 We should probably move discussion over there... Cheers, Joern. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 148] Add support for Structured Data
by bugzilla-daemon＠pixie.qos.ch 07 Sep '11

07 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=148 John Vasileff <git(a)netcc.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |git(a)netcc.us --- Comment #10 from John Vasileff <git(a)netcc.us> 2011-09-07 19:32:23 CEST --- I am trying to better understand requirements for StructuredData to go along with my proposal for bug 31. For use cases, do the following make sense? 1. Appender, please add values from the provided Map to the log entry in the best way you can. The map's data is more transient than MDC data, so I am providing it here. 2. Appender, please add this rfc compliant StructuredData to the log entry in the best way you can. Similar to #1, but with a StructuredData object instead of a Map. 3. Logger, I don't have a message for you, but please format this Map/StructuredData as the message. 4. Logger, I am providing you with NDC, MDC, and/or transient Map/StructuredData. Please format my log message taking these key/value pairs into account using a new log format that supports {key}, or even {[NDC|MDC|MAP]:key}. Also, please attach NDC, MDC, and Map/StructuredData to the log entry in the best way you can. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 31] Varargs for Logger methods
by bugzilla-daemon＠pixie.qos.ch 07 Sep '11

07 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #94 from John Vasileff <git(a)netcc.us> 2011-09-07 16:57:10 CEST --- (In reply to comment #91) > I see 3 possibilities to dealing with changes in SLF4J: > 0) disallow any meaningful changes to SLF4J > 1) allow for breaking compatibility for adapter implementations (as done > historically in SLF4J) > 2) come up with an abstraction so flexible that it is future proof for the next > 10 years. > 0 and 1 are doable. 2 requires great foresight. I suppose it is imposible to guarantee #2, but at least we can try! It may help to distill the contract between SLF4J and logger/adapter implementations into the fundamentals. An intial attempt: Adapters require access to: - The level & marker - The raw & formatted messages (raw for filtering only?) - The throwable, if exists - The processed arguments (strip trailing throwable). For performance reasons, adapters may also have access to the raw arguments. Sharing unpressed arguments is a performance tradeoff and should be avoided when possible. SLF4J requires from adapters: - isEnabled(marker, level) - ability to submit logs to adapters (obviously) Division of responsibilities: - SLF4J should fully control formatting, if applied. Allowing individual implementations to control the style of formatting violates the pluggable nature of back end logging frameworks. - SLF4J should fully control the application facing API. - SLF4J reserves the right to provide additional functionality so long as "Adapters require access to" points are satisfied (XLogger). I think the pros/cons of pluggable formatting is a separate debate, but providing a framework for things like this is relevant. The proposed Abstract[Raw]Logger would allow for future enhancements like: Logger myLogger = LoggerFactory.getLogger(MyClass.class) .formatWith(SLF4JFormatters.JAVA_UTIL_FORMATTER); or even: Logger myLogger = LoggerFactory.getLogger(MyClass.class) .formatWith(myFormatterInstance implements SLF4JFormatter); -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 31] Varargs for Logger methods
by bugzilla-daemon＠pixie.qos.ch 07 Sep '11

07 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #93 from Ralph Goers <rgoers(a)apache.org> 2011-09-07 16:17:36 CEST --- I believe I've implemented most, if not all, of the things being requested here in the Log4J 2.0 API. Feel free to review it and use it however you want. You can find it at https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIME…. OTOH, as a PMC member on the Log4j project you are more than welcome to simply work with me there and help me get it out of its sandbox. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 31] Varargs for Logger methods
by bugzilla-daemon＠pixie.qos.ch 07 Sep '11

07 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #92 from John Vasileff <git(a)netcc.us> 2011-09-07 16:13:42 CEST --- (In reply to comment #90) > (In reply to comment #89) Joern, thanks for reviewing this. > All maybeLog(...)-methods in NamedLoggerBase are calling the same > private void log(Marker marker, Level level, String msg, Throwable t) > method, already formatting the message and dropping any info about the argument > array and message pattern that was used to call it. I pushed an update for NamedLoggerBase to improve compatibiltiy. It now delegates to the existing Object[] logging methods and no longer performs formatting. > I can't help but feel dirty defining an interface like this... Well.. I agree, this adds a lot of methods to the API. It is relatively easy to code if the burden is removed from _each_ logger implementation, but it is still end user facing. It really comes down to whether or not we care about the current 1ns or so penalty and subsequent gc. Future VMs (and processors) may optimize this, but my hunch is that an implicit array will always be created. I'm somewhat neutral on this. Maybe looking at the resultant javadocs would change my mind. > The fact that (optional) formatting is happening in the adapters is not an > issue but a feature. > Message formatting is an implementation detail and different frameworks can > handle it in different ways (e.g. postpone it as in my Logback example). Got it. It does however seem valuable to simplify requirements for logger implementors. Everyone implemntation requires solving the same problems of 1) maintaining compatibility, and 2) implementing numerous similar methods. Enhancements like "Bug 70" should be possible without updating implementations everywhere. The same for possible future formatting or other features as you mentioned. An adjustment to #4's AbstractLogger: protected abstract void log( Marker marker, Level level, String msg, Throwable t, String rawMsg, Object[] argsWithoutTrailingThrowable); And an alternate AbstractRawLogger (implementor's decision which to use): protected abstract void log( Marker marker, Level level, String rawMsg, Object[] rawArgs); protected final Message format(String rawMsg, Object[] rawArgs); public interface Message { // similar to comment #61 but also include the "processed" args that // exclude the optional last arg throwable. Initially this would be // an instance of "FormattingTuple implements Message" String getFormattedMessage(); Throwable getThrowable(); Object[] args; } > Agreed, but it must be possible to use 1.6.x and 2.0 side-by-side. Original items #1 - #3 allow full 1.6 <-> 2.0 mix and match, and may even provide "perpetual support" of 1.6 loggers. Probably pointless, but support could even be re-added for even older loggers (pre-TRACE?). Original item #4 would require 2.0+ for any loggers implementing AbstractLogger or AbstractRawLogger. But it seems like the best time for something like this would be when JDK 5 is introduced. And if Abstract[Raw]Logger is well thought out, it will provide very long term compatibility while not restricting future enhancements. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 31] Varargs for Logger methods
by bugzilla-daemon＠pixie.qos.ch 07 Sep '11

07 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=31 Ceki Gulcu <listid(a)qos.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |listid(a)qos.ch --- Comment #91 from Ceki Gulcu <listid(a)qos.ch> 2011-09-07 15:57:36 CEST --- Fixing common functionality in an abstract class can alleviate some of the compatibility issues. The idea of reducing adapter implementations to two simple methods is quite brilliant. Nevertheless, Joern makes good points regarding early formatting. Message parameters must reach the logging backend unchanged whenever the backend has the appropriate hooks, e.g. logback. I am guessing that the idea of reducing adapter implementation can still be achieved albeit with different method signatures. Now imagine the following thought experiment. Assume that come up with some code structure which reduces adapter implementations two a handful of methods for all backends. At a later stage, assume we wish to enhance the org.slf4j.Logger interface with new functionality, say support for Joern's Message objects. The aforementioned methods would need to be modified to support Message objects breaking compatibility with existing adapter implementations. I see 3 possibilities to dealing with changes in SLF4J: 0) disallow any meaningful changes to SLF4J 1) allow for breaking compatibility for adapter implementations (as done historically in SLF4J) 2) come up with an abstraction so flexible that it is future proof for the next 10 years. 0 and 1 are doable. 2 requires great foresight. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0