-
Notifications
You must be signed in to change notification settings - Fork 136
IGNITE 19148 Switch tests from using JUL to log4j2 #2429
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
Conversation
6d8d434 to
3a1c282
Compare
|
|
||
| lock.writeLock().lock(); | ||
| try { | ||
| for (Handler handler : handlers) { |
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.
Collections.addAll(this.handlers, handlers);
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.
Thanks. Fixed
rpuch
left a comment
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.
What's the reason to change from JUL to log4j2? The JIRA only says about logging to stderr, but JUL can be configured to use any appenders (or how are they called there?) we want. So why?
|
|
||
| Handler physicalTopologyWaiter = physicalTopologyWaiter(allNodesAreInPhysicalTopology); | ||
| topologyLogger.addHandler(physicalTopologyWaiter); | ||
| TestLogChecker topologyLogger = new TestLogChecker( |
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 not a logger, this is a checker. I suggest to rename this accordingly
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.
You are absolutely right. Will fix it here and in other places.
| import org.apache.logging.log4j.core.config.Property; | ||
|
|
||
| /** | ||
| * Test log checker. |
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.
Let's expand the documentation with an explanation of what this checker does, what checks it performs, how it can be used
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.
Javadoc was added.
| * @param loggerName Logger name. | ||
| * @param predicate Predicate to check log messages. | ||
| */ | ||
| public TestLogChecker(String loggerName, Predicate<String> predicate) { |
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.
What happens if the predicate returns true or false?
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.
Also, in some cases it is required to verify other message attributes, not only its text (for instance, we might want to verify that a message is logged as a WARN). Let's make the predicate accept the whole message, not just its text.
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.
What happens if the predicate returns true or false?
updated javadoc in the following way:
/**
* Creates a new instance of {@link TestLogChecker} with the given {@code predicate}.
* In order to check that the required log event was logged, use {@link #isMatched()} method.
*
* @param loggerName Logger name.
* @param predicate Predicate to check log messages.
*/
Also, in some cases it is required to verify other message attributes, not only its text
It makes sense to me. Predicate should acceptLogEventinstead ofString
| } | ||
|
|
||
| /** | ||
| * Creates a new instance of {@link TestLogChecker} with the given {@code predicate} and {@code action}. |
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.
There is no predicate among parameters, probably this needs to be adjusted
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.
Thanks. Fixed.
| public Handler addHandler(Predicate<String> predicate, Runnable action) { | ||
| Handler handler = new Handler(predicate, action); | ||
|
|
||
| lock.writeLock().lock(); |
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.
It seems we can just invoke addHandler(handler) 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.
Thanks. Fixed.
| private final TestMessagesFactory messageFactory = new TestMessagesFactory(); | ||
|
|
||
| /** List of test loggers. */ | ||
| private final List<TestLogChecker> loggers = new ArrayList<>(); |
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.
Those are not loggers, they are checkers
| private Cluster cluster; | ||
|
|
||
| private Logger replicatorLogger; | ||
| private TestLogChecker replicatorLogger; |
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 not a logger anymore, the field probably needs to be renamed
| AtomicBoolean snapshotInstallFailedDueToIdenticalRetry = new AtomicBoolean(false); | ||
|
|
||
| Logger snapshotExecutorLogger = Logger.getLogger(SnapshotExecutorImpl.class.getName()); | ||
| TestLogChecker snapshotExecutorLogger = TestLogChecker.create(SnapshotExecutorImpl.class); |
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 not a logger
| /** | ||
| * Test log checker. | ||
| */ | ||
| public class TestLogChecker { |
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 name does not seem perfect. 'Check' is too abstract; also this class not just 'checks' incoming log messages, but it also reacts to them somehow. Maybe a better name should be devised (but I cannot come up with anything good now)
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.
Renamed to LogInspector
…order to allow to check log level etc
sk0x50
left a comment
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.
Hi @rpuch,
I agree that this is my fault and I had to describe the motivation in the ticket.
IMHO
- It would be better to use a well-known and widely-used logging framework instead of JUL, which should not require any additional code like a custom appender, etc. I don't think that JUL is used in real-life solutions, so this patch can be considered a test scenario to use 3rd party implementation of the logging framework (For example, scalecube, which is an internal thing, uses slf4j and so we need to provide a bridge from slf4j to log4j2/logback. this step is not so obvious and has to be described in our documentation).
- log4j2 provides a color schema for the logs, which is a nice feature :)
By the way, I don't like our approach of using logs to check something like cluster initialization, snapshots, etc. It should be done via special lifecycle events, callbacks, whatever... but using logs for this looks weird to me.
...re/src/testFixtures/java/org/apache/ignite/internal/testframework/log4j2/TestLogChecker.java
Outdated
Show resolved
Hide resolved
…testframework/log4j2/TestLogChecker.java Co-authored-by: Roman Puchkovskiy <roman.puchkovskiy@gmail.com>
https://issues.apache.org/jira/browse/IGNITE-19148
Thank you for submitting the pull request.
To streamline the review process of the patch and ensure better code quality
we ask both an author and a reviewer to verify the following:
The Review Checklist
- There is a single JIRA ticket related to the pull request.
- The web-link to the pull request is attached to the JIRA ticket.
- The JIRA ticket has the Patch Available state.
- The description of the JIRA ticket explains WHAT was made, WHY and HOW.
- The pull request title is treated as the final commit message. The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
Notes