logging-log4j2
logging-log4j2 copied to clipboard
apache
LOG4J2-3122 fix Logging to Log4j2 MongoDb4 Appender get ERROR on trace, debug and info level.
After do some debugging, i found out that there are some part of the code that is missing in MongoDb4Provider class when creating log4j-mongodb4 module, knowing that this part of the code is exists in log4j-mongodb3 module. The code that check if the database actually requires authentication. I don't know if that is intentional or not but somehow this part of the code is what making the old log4j-mongodb3 module running without error. So i just copy the old code to the new log4j-mongodb4 module, and now it is running without error to. What do you think about this log4j2 team? Please respond. Thanks.
After do some debugging, i found out that there are some part of the code that is missing in MongoDb4Provider class when creating log4j-mongodb4 module, knowing that this part of the code is exists in log4j-mongodb3 module. The code that check if the database actually requires authentication. I don't know if that is intentional or not but somehow this part of the code is what making the old log4j-mongodb3 module running without error. So i just copy the old code to the new log4j-mongodb4 module, and now it is running without error to. What do you think about this log4j2 team? Please respond. Thanks.
Hi @redapel Yes, it was intentional, with the version 4 driver, anything should be configurable from the connection string, unlike with the version 3 driver IIRC.
In general, you'll want to provide tests for new code. If you'd included a test with a configuration file, we could have determined if that was the code... so it still might be the case, but, no test...
Hi team, Please have take a look to the new test case that i submitted. In that test, i choose to use real MongoDB server instead of the Flapdoodle's embedded MongoDB as the later can't be considered as "full integration testing", there are possibilities that both of them behaves differently, so it is better to use solution like docker container. By the way, i run the test using a replica set cluster with only single server act as a PRIMARY. I suggest you to run the test more than one (for example 10 times), Since there are at least 2 different error cases produced when i try to test it. Both of them i already made an assertion to fail the test. Let me know about the progress. Thanks.
Hi team, Please have take a look to the new test case that i submitted. In that test, i choose to use real MongoDB server instead of the Flapdoodle's embedded MongoDB as the later can't be considered as "full integration testing", there are possibilities that both of them behaves differently, so it is better to use solution like docker container. By the way, i run the test using a replica set cluster with only single server act as a PRIMARY. I suggest you to run the test more than one (for example 10 times), Since there are at least 2 different error cases produced when i try to test it. Both of them i already made an assertion to fail the test. Let me know about the progress. Thanks.
You'll want to fit in our existing test framework.
Hi team, Please have take a look to the new test case that i submitted. In that test, i choose to use real MongoDB server instead of the Flapdoodle's embedded MongoDB as the later can't be considered as "full integration testing", there are possibilities that both of them behaves differently, so it is better to use solution like docker container. By the way, i run the test using a replica set cluster with only single server act as a PRIMARY. I suggest you to run the test more than one (for example 10 times), Since there are at least 2 different error cases produced when i try to test it. Both of them i already made an assertion to fail the test. Let me know about the progress. Thanks.
You'll want to fit in our existing test framework.
I already change to Flapdoodle's embedded MongoDB