[
https://issues.apache.org/jira/browse/JENA-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294624#comment-17294624
]
Andy Seaborne commented on JENA-1867:
-------------------------------------
With 4.0.0, we have the chance to say "use log4j2". Or use JUL which is always
available. For getting debug info out, it's OK.
Bundling in log4j1 when it's got a CVE against it causes user problems because
code scanning will flag it up, which at a minimum is more user work. The CVE is
not new. They have increased the severity from it's first registration.
> Move jena-jdbc off log4j1
> -------------------------
>
> Key: JENA-1867
> URL: https://issues.apache.org/jira/browse/JENA-1867
> Project: Apache Jena
> Issue Type: Task
> Components: JDBC
> Affects Versions: Jena 3.14.0
> Reporter: Andy Seaborne
> Priority: Minor
>
> Now that JENA-1005 has been completed, the only part of Jena directly
> mentioning log4j1 is jena-jdbc. This controls log4j1 directly.
> {org.apache.jena.jdbc.JnaDriver}} and {{TestMemDriverWithLogging}}.
> The dependency on log4j1 is managed in jena-jdbc/pom.xml to isolate it from
> the rest of Jena and used in jena-jdbc-core/pom.xml.
> Possibilities include:
> # Bundle log4j2; possibly use {{LogCtl}} rather than code directly.
> # Remove it (is it documented outside javadoc?)
> # Continue with log4j1 can record the fact for the automated GH security scan
> of dependencies.
> (2) is motivated by my lack of knowledge about how visible the feature is and
> whether such "logging less" use case arise nowadays.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
