If memory serves this was because depending upon the context in which you try and use the JDBC drivers you may not otherwise have any way to set a logging level and get log output for debugging.
For example consider an arbitrary 3rd party tool e.g. Tableau, Pentaho, Squirrel SQL - typically the user can provide a path to the JDBC driver JAR and a JDBC connection string and that app might not even be running the driver locally so no way to provide a separate log4j configuration file to it short of baking one into the JAR which doesn't allow for runtime customisation. I believe it is possible to do the same kind of stuff that it does currently with Log4j1 i.e. basic programmatic configuration with Log4j2 as well so there is a migration path possible Rob On 16/03/2020, 16:13, "Andy Seaborne" <[email protected]> wrote: Rob - jena-jdbc directly controls log4j1. Is this necessary for some reason? What are the requirements here? 1/ log4j1 needs retiring due to the CVE (even if if it does not really affect us) 2/ It isn't simple to surpress messages like WARN info :: Attempt to close a DatasetGraphTransaction .... because the tests log but log4j1 is on the classpath and the log4j2 helper code can't surpress the messages. (there again jena-text-es is very, very messy in tests) Andy
