Log statements changed from debug to trace level #516
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ng is enabled. Also added assertj and commons-io Maven dependencies for use in the tests. Commons IO is used to compare template output to expected output that is loaded from a file. Loading the expected template output from a file is useful for testing multiline template output, which is necessary to test various scenarios. These are a form of Integration Test rather than Unit Tests and so it is practical and reasonable to verify the template output in this way.
…hanged the test method names in some cases to make the purpose of each test method more clear.
…atement Thatis Skipped test
…hich I found useful to see in log statements.
…provides more evidence that the Pebble syntax is good. Jinja is a very popular Python template engine.
…l log statements in LexerImpl, PebbleEngine and LexerImpl that were useful to me when trying to follow the code. Added logback-test.xml to configure the logging level. Disabled the debug logging by default. Also removed Hamcrest Matchers and replaced references to Hamcrest in exception testing code with AssertJ. Also, changed the name of a few private methods in LexerImpl for improve clarity.
…statements were being output by default. Trace statements are not output unless configured to do so.
|
Is there a reason to change these four lines to trace ? |
|
Yes. The default log level for logback is DEBUG. When I use Pebble in my application that does not have an explicit log level specified (i.e. no logback.xml file), the DEBUG statements are produced. Therefore, this probably happens for other people as well. This was not the case until the latest release of Pebble because I added these log statements last year when trying to understand the Pebble Lexer code. These statements are useful for that purpose, but TRACE would be a reasonable level for these statements. Also, I did use TRACE level in the LexerImpl code. So, this makes the log level consistent for these type of log statements. Do you want me to submit an issue for this for records purposes? Here's an example of the log statements. These should not be produced unless someone specifically configures logback to produce them. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.