On 16/03/2020 17:00, Rob Vesse wrote:
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.
How does the user switch it on or off?
Are the control properties arguments to the JDBC driver via URL or JVM
system properties?
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
LogCtl abstracts from having to know the logging implementation. It is
not very pretty internally.
It can be migrated but old properties files will not work. log4j2 uses a
different format and normally a different file name.
I can't find this in documentation to know the impact.
We can leave it as-is and clear the CVE alert. It is not in the
artifacts that users deploy directly, it is in a code library.
(I'd prefer to clear things out for the long term.)
Andy
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
