-
Notifications
You must be signed in to change notification settings - Fork 411
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[#126] Changing the log level in config.json does not work #187
[#126] Changing the log level in config.json does not work #187
Conversation
Click here to submit a new iteration when this PR is ready for review. See this repository's contribution guide for more information. |
Codecov Report
@@ Coverage Diff @@
## master #187 +/- ##
============================================
- Coverage 73.96% 73.82% -0.14%
+ Complexity 420 415 -5
============================================
Files 71 71
Lines 1279 1276 -3
Branches 126 126
============================================
- Hits 946 942 -4
- Misses 301 302 +1
Partials 32 32
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
v1@Eclipse-Dominator submitted v1 for review.
Checkout this PR version locallygit fetch https://github.com/se-edu/addressbook-level3.git refs/pr/187/1/head:BRANCHNAME where |
ac5083b
to
e2e1df5
Compare
v2@Eclipse-Dominator submitted v2 for review.
(📚 Archive) (📈 Interdiff between v1 and v2) (📈 Range-Diff between v1 and v2) Checkout this PR version locallygit fetch https://github.com/se-edu/addressbook-level3.git refs/pr/187/2/head:BRANCHNAME where |
9047b48
to
2649a9f
Compare
v3@Eclipse-Dominator submitted v3 for review.
(📚 Archive) (📈 Interdiff between v2 and v3) (📈 Range-Diff between v2 and v3) Checkout this PR version locallygit fetch https://github.com/se-edu/addressbook-level3.git refs/pr/187/3/head:BRANCHNAME where |
A consideration is whether we should have a method that creates loggers that ignore the current log level such as the logger that prints |
As per the current PR, will they be skipped if the logging level is set to higher than |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few questions ... to help me understand the code better.
Yes, as per current PR, this will indeed be skipped |
2649a9f
to
0c8720c
Compare
v4@Eclipse-Dominator submitted v4 for review.
(📚 Archive) (📈 Interdiff between v3 and v4) (📈 Range-Diff between v3 and v4) Checkout this PR version locallygit fetch https://github.com/se-edu/addressbook-level3.git refs/pr/187/4/head:BRANCHNAME where |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a follow up question
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some cosmetic suggestions
02f5871
to
075ca3a
Compare
v5@Eclipse-Dominator submitted v5 for review.
(📚 Archive) (📈 Interdiff between v4 and v5) (📈 Range-Diff between v4 and v5) Checkout this PR version locallygit fetch https://github.com/se-edu/addressbook-level3.git refs/pr/187/5/head:BRANCHNAME where |
After some experimentation, I think using the inheritance of base loggers will lead to a much cleaner and simpler code as compared to statically storing both file and console handlers. The new changes here still enables the following:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a query and a suggestion.
Logger baseLogger = Logger.getLogger(BASE_LOGGER_NAME); | ||
baseLogger.setUseParentHandlers(false); | ||
removeHandlers(baseLogger); | ||
baseLogger.addHandler(createConsoleHandler(Level.ALL)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why use Level.ALL
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is to ensure that all the handlers will log messages regardless of their level. So we dont need to track these loggers as a global variable in the class.
Since the logger is the one generating the messages, we dont want the level of the handlers to be higher than the log level of the loggers as this will cause the messages of the loggers to be ignored by the handler. (e.g. logger set to FINEST but handler is at INFO)
Since both handlers will always all messages by generated by the logger, there is no need to purposefully set the log level of each handler. Furthermore, setting these handlers to ALL won't impact performance since they are just comparing the log levels of the messages.
075ca3a
to
deb33a6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of things I missed out earlier
@se-edu/tech-team-level1 for your review ... |
7ba7de2
to
8775e85
Compare
v11@Eclipse-Dominator submitted v11 for review.
(📚 Archive) (📈 Interdiff between v10 and v11) (📈 Range-Diff between v10 and v11) Checkout this PR version locallygit fetch https://github.com/se-edu/addressbook-level3.git refs/pr/187/11/head:BRANCHNAME where |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
However, I noticed in the provided screenshot that the default logging level is set to 'info', even though all the messages pertain to configuration. It might be more appropriate to set the logging level to 'config'. This observation may lead to a new issue.
Interesting suggestion @SPWwj We can look into this separately. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found some of the comments have the right description but they appear at the wrong place. While tweaking them, I also encountered a method that may not be the right abstraction.
private static Logger getBaseLogger() { | ||
Logger baseLogger = Logger.getLogger("ab3"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current role of this method doesn't feel right. It returns something that is meant to be used as the baseLogger but it has no control over how it will be used.
The following feels like a better fit for what the method does.
private static Logger getBaseLogger() { | |
Logger baseLogger = Logger.getLogger("ab3"); | |
private void setBaseLogger() { | |
baseLogger = Logger.getLogger("ab3"); |
It can be called inside the init() method. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would still prefer the original method, as init()
is only called after the config file is being read.
This will cause the baseLogger
to be uninitialized before then.
To prevent this, LogsCenter
might need to switch to using a getter method to retrieve the baseLogger
(initialize it if it is not defined) which is not really ideal since baseLogger
itself is a private attribute of LogsCenter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that is a major problem, compared to an abstraction that doesn't sound right. But if you want something to execute earlier, you can use a static
code block. See CommandTestUtil.java
for an example. Would that work? e.g.,
static {
setBaseLogger();
}
d89264d
to
a93f10a
Compare
v12@Eclipse-Dominator submitted v12 for review.
(📚 Archive) (📈 Interdiff between v11 and v12) (📈 Range-Diff between v11 and v12) Checkout this PR version locallygit fetch https://github.com/se-edu/addressbook-level3.git refs/pr/187/12/head:BRANCHNAME where |
FileHandler fileHandler = new FileHandler(LOG_FILE, MAX_FILE_SIZE_IN_BYTES, MAX_FILE_COUNT, true); | ||
fileHandler.setFormatter(new SimpleFormatter()); | ||
fileHandler.setLevel(Level.ALL); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be refractor as a new function private static setFileHandler()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SPWwj Yup, if we go for strict SLAP, this can be extracted as a separate method. But in some cases it is OK to keep two levels inside a method, to reduce unnecessary method proliferation. So, a code block preceded by a comment that explains what the code block does is as good as extracting that code block as a method, provided that code block is needed only once.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Occam's Razor 😂
a93f10a
to
7e88b47
Compare
v13@Eclipse-Dominator submitted v13 for review.
(📚 Archive) (📈 Interdiff between v12 and v13) (📈 Range-Diff between v12 and v13) Checkout this PR version locallygit fetch https://github.com/se-edu/addressbook-level3.git refs/pr/187/13/head:BRANCHNAME where |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few cosmetic suggestions.
// The logger that will be used as the parent of all other loggers created by this class. | ||
private static final Logger logger; | ||
private static Logger baseLogger; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// The logger that will be used as the parent of all other loggers created by this class. | |
private static final Logger logger; | |
private static Logger baseLogger; | |
private static Logger baseLogger; // to be used as the parent of all loggers | |
private static final Logger logger; // logger for this class |
Perhaps just end-of-line comments (as suggested above) are enough here?
I put baseLogger above logger because I felt it is more intuitive to learn about baseLogger first. But either order is OK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason why one is final but the other is not?
7e88b47
to
d5599da
Compare
v14@Eclipse-Dominator submitted v14 for review.
(📚 Archive) (📈 Interdiff between v13 and v14) (📈 Range-Diff between v13 and v14) Checkout this PR version locallygit fetch https://github.com/se-edu/addressbook-level3.git refs/pr/187/14/head:BRANCHNAME where |
@se-edu/tech-team-level1 for your review ... @SPWwj the code has changed since your last review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No further comments from me. Thanks for the persistence with this PR @Eclipse-Dominator
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just some nitty-gritty changes to make the message more consistent.
The current way of initializing loggers causes all loggers to default to INFO level, even if a different level is specified via the config.json or programmatically. Let's create a logger named `ab3` to serve as the base logger, and automatically prefix all loggers created using LogCenter#getLogger(...) with `ab3.` so that they all become descendants of the base logger. This allows us to change the logging level of all loggers simply by changing the logging level of the base logger (unless those loggers have specified their own logging level). Implications: Loggers not created using the LogCenter#getLogger(...) methods will not come under the above control mechanism unless their name starts with `ab3.`.
d5599da
to
6e7104b
Compare
v15@Eclipse-Dominator submitted v15 for review.
(📚 Archive) (📈 Interdiff between v14 and v15) (📈 Range-Diff between v14 and v15) Checkout this PR version locallygit fetch https://github.com/se-edu/addressbook-level3.git refs/pr/187/15/head:BRANCHNAME where |
Fixes #126
The current way of initializing loggers causes all loggers to default to
INFO
level, even if a different level is specified via theconfig.json
or programmatically.Let's create a logger named
ab3
to serve as the base logger, and automatically prefix all loggers created usingLogCenter#getLogger(...)
withab3.
so that they all become descendants of the base logger. This allows us to change the logging level of all loggers simply by changingthe logging level of the base logger (unless those loggers have specified their own logging level).
Implications: Loggers not created using the
LogCenter#getLogger(...)
methods will not come under the above control mechanism unless their name starts withab3.
.A simple demo for
log level = FINEST
A simple demo for
log level = WARNING
There is a small change in the behavior of init, previously, changing the log level will cause all subsequent loggers to have their log level changed, however, currently, this implementation changes all loggers created from the application.
However, some classes like AddressBook etc are created before log level is being updated and I am afraid that this might defeat the purpose of changing the log levels.
Another minor thing I noticed: comment
The current code base mostly uses
INFO
and I believe it might be more helpful if we reclassify some of the logs to usewarning
and higher like changing logs caused by incorrect command toWARN
and logs caused by IOException toFATAL/ERROR
.