oodt
oodt copied to clipboard
apache
[OODT-1021] Unify Logging through SLF4J
There are multiple logging APIs used in OODT at the moment, including JUL and Log4J. There has been some progress converting them to SLF4J and adding SLF4JBridge to ease the migration. However, in components such as Filemgr, logs do not appear on Console and only gets written to log files, making it hard to debug OODT overall.
Please note that this PR is an extensive overhaul and includes changes in 300+ source files. However, all changes are related to migrating to SLF4J APIs and includes few additional logs in filemg
I like this PR, the logging in OODT has always been a right PITA trying to find the right stuff in the right file/console output. I'm very much +1 to this.
@yasithmilinda really sorry I did not see this patch. Are you able to update against master branch? I will review. Sorry about this...
Hello @lewismc and @buggtb, it's been a while since I added this PR. I'll give it a shot this week and see where I get.
@lewismc, I've updated it against the master branch. Appreciate if you can review it. Cheers!
@yasithmilinda Thanks for updating the PR. Were you able to do some quick tests with this? Like building OODT pack and running everything to see if log files are created as expected?
@lewismc since this is just a logging change, do you think this won't break anything?
@IMS94 I only ran basic tests by creating a new project from the radix archetype. I'm not entirely sure which log files are expected to be created. Can you point me to a sample workflow (or instructions) that I can run this PR and test on?
@yasithmilinda You can simply build the OODT distribution and, run oodt start. Check if all the services (filemgr, resmgr and workflow manager) comes up without an issue (you can use the status page to see if services are running). Then, if all are running, you can check if the log files are created under ${component_directory}/logs folder (ex: filemgr/logs).
My only concern is, when running, say file manager, that shell script passes in the logging.properties file which is for JUL. When we were using JUL within the applications, this works fine. Now, when we have changed the logging within applications to slf4j (log4j2), we are not providing a log4j2.xml in that shell script (correct me if I'm wrong). This may cause the logs to not be printed properly in the log files. However, I remember I did some log4j2 migration sometime back, in which I added the log4j2.xml files and used the log4j2 jul adapter to print JUL logs in log4j2 log outputs. It will be great if you can double check. If log4j2.xml is there, then your changes will work without any issue.