[slf4j-dev] Release of SLF4J version 1.6.0-RC0

[Ralph Goers]

On May 1, 2010, at 3:37 AM, Joern Huxhorn wrote:

> 
> How about only adding
> 
> logger.debug(Message)
> logger.debug(Message, Throwable)
> 
> leaving out the Marker?
> 
> That way the Message implementation might opt-in to add Marker-support as seen fit.
> 
> I'd like to point out, though, that I haven't thought this through, yet.
> 
> I think it would likely create rather big problems, including TurboFilters that won't properly match on Markers anymore... which would create a large amount of confusion for the user.
> 
> The main-point of Markers, for me, is the ability to use them for efficient filtering in Logback (and Lilith).
> 
> I never liked the hierarchy-aspect of them, especially since they are supposed to be global.

I don't mind the hierarchy. I've just found them to be awkward because you have to call add. It would have been much more natural to have one marker class extend another if you want that kind of relationship.

> 
> In my opinion, the marker-hierarchy shouldn't be created in the software but in the configuration instead. Under no circumstance should other modules be able to change my marker-hierarchy.  I once reported a bug about recursive marker-hierarchies that you fixed by preventing recursion at all. This has the effect that the module that creates the Marker first will be able to decide on the hierarchy while a module loaded later-on in the application will be stuck on the previously created hierarchy - even if it's logging is expecting an entirely different one. This is a catastrophe waiting to happen - which is why I'm not using them in that way in my code.

I'm not sure how you create a marker in the configuration when it is used in the code.  What would debug(MY_MARKER, msg) do if MY_MARKER wasn't defined?

> 
> I'm also not sure about possible classloader-woes concerning MarkerFactory. [1][2]
> I haven't checked this but I suspect there could be problems with Markers comparable to those of custom java.util.logging.Level.
> 
> Beside that, I think the Markers ENTERING, EXITING and THROWING should be used without being put into a TRACING marker. The grouping of those three markers into a TRACING group should be done in the Logback config and filters could then filter on that group.

I disagree with this. First off, ENTERING and EXITING use a FLOW marker, not TRACING. THROWING and CATCHING extend EXCEPTION. This makes sense because it lets you filter on FLOW events as a whole or just entry events if you want.

> But this after-the-fact discussion isn't helping anymore.
> One way to fix it, though, would be not caching Markers in MarkerFactory at all.
> 
> The use-case described by Gunnar could (and IMHO: should) be handled using the MDC, not Markers. He could call MDC.put("CONFIDENTIAL","true") and perform special handling that way.

I would only recommend the MDC be used for data that could possibly span log events. Having to set it and remove it after each logging call would be a pain. Markers work better for this.

> 
> Both ways assume that the Logging system is evaluating either Marker or MDC which isn't the wisest thing to do.
> Confidential info should NEVER be logged, IMHO, regardless of the logging configuration.

Sometimes it has to be. Trying to diagnose problems often requires this kind of information. Also, audit logs will often contain confidential or sensitive information. We have different levels of classification of data. A user's bank account number might appear in a log. A user's PIN or password will never appear.

Ralph