stevedlawrence opened a new pull request, #954: URL: https://github.com/apache/daffodil/pull/954
- Remove all uses of log4j. Instead, Daffodil now uses SLF4J (MIT license) via the scala-logging library (ALv2 licnse). This makes Daffodil more flexible as to which logging backend is used. Additionally, SLF4J has a simpler backend API, so creating custom backends is much more straightforward. - Implement a custom SLF4J backend via a custom ServiceProvider, LoggerFactory, and Logger that supports thread specific log Levels and PrintStreams. Note that each thread must explicitly configure the logger with the level and stream, or else this new backend silently drops log messages. - Put this new SLF4J backend on the CLI classpath so the CLI uses this thread safe logging, needed for parallel tests. - Put this new SLF4J backend on the TDML processor classpath. The TDML Runner does not currently configure this new logger, so logs are just dropped (essentially the same behavior as we have now), but this avoids error messages from SLF4J about not having a logger available. It also means in the future we can easily configure this logger to give the TDML runner the ability to capture and expect log messages. Additionally, this resolves errors when the log4j-api version did not match a log4j-core version defined in a DFDL schema project. The TDML runner now requires this custom backend, so users do no need to specify one. - Put this new SLF4J backend on all other subprojects in the test configuration. This way, if a unit test runs code hat logs, then it ensures a logger is available and avoids an SLF4J warning. Note however that since no tests configure the logger, the logs will be dropped. Also note that this is only for the "test" configuration, not "compile" or "runtime", and so API users must add a custom SFL4J backend or they will get a warning from SLF4J. This is similar to the existing behavior where users needed to add a log4j backend, but avoids API mismatches since SLF4J has better backwards compatibility. - Because the custom logger is used for the TDML runner as well, there are no longer any issues with DFDL schema projects depending on a different version of log4j than is used by Daffodil. If they already depend on log4j with this update, it will simply not be used. - Also correct subprojets made up of tdml tests to depend on tdmlProc in the "test" configuration. This doesn't really matter but is technically correct. - Change the CLI Main object to a class that can be instantiated with custom streams instead of sharing global mutable state. The Main object now just creates an instance using normal stdin/out/err, but tests create a Main instance using test/thread specific streams. - Modify the CLI to configure the custom SLF4J logger so different instances that are run in different threads can log to a different streams and levels. - These changes now make CLI tests completely thread safe, so parallel CLI tests are enabled. Backwards/Compatibility: Daffodil now uses SLF4J for logging instead of log4j. API users may need to add a new dependency to specify which logging backend to use, for example slf4j-log4j for the previous behavior. If no backend is found, a warning will be output to stderr and log messages will be dropped. DFDL schema projects that previously added log4j-core (or another log4j implementation) as a dependency to avoid warnings no longer need that dependency--a custom Daffodil specific logger is now used for TDML tests and is automatically pulled in as dependency. DAFFODIL-2778, DAFFODIL-2787 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
