[logback-dev] [JIRA] Commented: (LBCLASSIC-273) Status messages of StatusManager are not cleared upon call to LoggerContext.reset()

[Joern Huxhorn (JIRA)]

    [ http://jira.qos.ch/browse/LBCLASSIC-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12053#action_12053 ] 

Joern Huxhorn commented on LBCLASSIC-273:
-----------------------------------------

Well, the changes would certainly "work" as described but I can't say that I'm very happy with them...

The removal of StatusManager.getLevel() actually happened in [1] and it is a breaking change of the public API. I think that having a method like this, arguably better named getHighestStatusLevel() or getHighestLevel(), is really desirable and quite crucial to the StatusManager interface.
I'd rather deprecate getLevel() and add a new method with a better name as a replacement instead of simply removing it and breaking existing code in the process.

I'll now be arguing from the point of view of a person that is not aware of this ticket.

My problem with your approach is that it absolutely requires reading the documentation. If I just use StatusManager as retrieved from LoggerContext I'll definitely use it in a wrong way.

Instead, I'm expected to use another class, namely StatusChecker, that I've never heard of before (i.e. I have no chance to "reach" StatusChecker by means of IDE-code-completion, neither is StatusChecker mentioned in the documentation of StatusManager, Context or ContextBase).

StatusChecker, if I've been able to actually find it, contains a bunch of methods that expect a rather obscure "long threshold" argument without any additional documentation at all. So now I'd even need to search the non-sourceode documentation, assuming that StatusChecker is documented there.

Ideally, an API should "just work" without having to take a look at the documentation at all (the POLA-Principle).

If I call reset() on a LoggerContext, I naturally believe that the status messages of its StatusManager are cleared, too. This is the reason for this whole ticket. Both my co-worker and I expected this and we both assumed that the current behavior was simply a bug rather than a misunderstanding on our side.

If I really want to keep previous status messages (something that is an exception to the default and expected way of behavior) then I can just simply get a copy of the status list prior to calling reset(). No big thing.

I don't understand why you make the handling of status messages overly complicated for a casual user just to support a rare corner-case (keeping status messages across several reset()-calls) which could be easily implemented in a different way by manually saving a copy of status messages in only those cases.

If you really want to support the keeping of status messages out of the box (which I wouldn't) then the whole threshold stuff should be handled in the StatusManager internally, e.g. setting threshold automatically on call to clean() and adding methods to retrieve the entire Status list instead of just the status messages after the last clean() call (the default behavior).

The changed documentation of the LoggerContext.reset() method wouldn't have prevented our initial problem either since we didn't take a look at the documentation before we realized that there was an issue (POLA again). It would now merely cut down on the debugging time but would still cause the same "D'oh!" effect.

[1] https://github.com/ceki/logback/commit/33a24d81695f2a90ed239c0054225992c6be4aab

> Status messages of StatusManager are not cleared upon call to LoggerContext.reset()
> -----------------------------------------------------------------------------------
>
>                 Key: LBCLASSIC-273
>                 URL: http://jira.qos.ch/browse/LBCLASSIC-273
>             Project: logback-classic
>          Issue Type: Bug
>    Affects Versions: 0.9.28
>            Reporter: Joern Huxhorn
>            Assignee: Logback dev list
>
> See https://github.com/ceki/logback/pull/15

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira