[query] use log4j-api-scala for string interpolation

[ehigham]

Readers are encouraged to read the log4j documentation on performance considerations. This change is motivated by a number of the issues discussed therein.

We do a lot of string interpolation in logs which isn't great as these logging APIs use call by ref instead of call by name.

log4j-api-scala uses macros to transform string-interpolated log statements into efficient java versions, making sure we're not building strings needlessly.

Their doc suggests inheriting from Logging​ and using the protected logger​ field. One benefit of doing things this way is that logs contain the name of the enclosing class without analysing the call stack. I find it much easier to find where a log statement was generated within the source code as a result.

The trouble with this Logging​ trait is that the loggeris not reconfigurable for reasons I'm yet to fully understand. I think it has something to do with specifying the class loader to log4j's LoggingFactory​..? Anyway, I repurposed our Logging​ trait to provide the protected logger​ member that is reconfigurable.

This change cannot impact the Hail Batch instance deployed by Broad Institute in GCP

[ehigham]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• [query] use log4j-api-scala for string interpolation #15181 👈 (View in Graphite)
• [query] run ServiceBackend in Py4jQueryDriver #14984
• [query] use log4j2 #15176
• [query] read hail-generated cloud credentails #15160 : 1 other dependent PR (#15161 )
• [query] simplify DeployContext #15159
• [query] engoodening of the py4j clients #15158
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.