Use the instance class as the logging category #69
Conversation
|
Travis says I made a mistake here. I'll fix that before you should look at it. |
61b24f5 to
3467ad2
Compare
Per Log::Log4perl's recommendation (see https://metacpan.org/pod/Log::Log4perl#Pitfalls-with-Categories), use the class of the instance as the category for purposes of logging -- where possible. This allows much better control over which parts of the application do logging and which parts don't.
3467ad2 to
3e79314
Compare
Fixed. |
|
@jonasbn this branch is ready to be merged. The reason it says checks are failing is because coverage dropped by 0.1%, which is a consequence of me having removed more tested than untested code lines. Please review. |
|
Hi @ehuelsmann Even though it looks massive, the theme of the PR is somewhat uniform. I do not expect this PR review to be as extensive. I will see if I can find the time shortly. |
|
@jonasbn no hurry; this one is indeed much simpler than the other one. If I can choose, I also prefer this one, because it touches more code and would be nice to have that out of the way for any further PRs. The other one is much more localized. |
jonasbn
left a comment
There was a problem hiding this comment.
Hi @ehuelsmann
I have made some minor remarks. Could you please go over them. One is cosmetic and two are actually the same pattern, where I might just be missing something.
Co-authored-by: Jonas Brømsø <[email protected]>
The Id generating classes referred to the `log` method, which neither defined. This commit defines a `log` accessor for the attribute by the same name. Incidentally align the implementations of `SequenceId` and `AutoGeneratedId` in that they both document their properties, both define a `new` method and both define a `log` attribute now.
|
Hi @ehuelsmann I think we should consider releasing this as a major release based on your initial comment and flagging as the PR as breaking |
Yes, I think that you're right. It's a more strict interpretation of SEMVER than I would have used on my own software, because I consider logging more of a secondary or supporting functionality -- I wouldn't have thought to apply SEMVER to that too (as the primary functionality and documented API didn't change). Anyway, a question that comes up when you say that is: should we then plan for more rigorous change? Maybe changes including the API? |
Minor addition to change log, an important PR (#69) was not listed
Description
Per Log::Log4perl's recommendation (see https://metacpan.org/pod/Log::Log4perl#Pitfalls-with-Categories),
use the class of the instance as the category for purposes of logging -- where possible.
This allows much better control over which parts of the application do
logging and which parts don't.
Type of change
The reason I'm considering this a breaking change is because logging configuration might need to be adjusted for inherited classes (not for Workflow classes themselves): Since I don't expect there to be a specific logging configuration for the
Workflowcategory, all the loggers will fall back to the current default, which they already did by callingget_logger(). For any inherited loggers in different toplevel namespaces (e.g.LedgerSMB::Workflow::Action::Email), a different logging category may be selected (i.e.LedgerSMB), resulting in different logging results than before.Where to document this?
Checklist: