[
https://issues.apache.org/jira/browse/JENA-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294590#comment-17294590
]
Rob Vesse commented on JENA-1867:
---------------------------------
I took a look at this a while bag, we can't just drop in log4j2 because there's
no equivalent ability to dynamically configure the logging in the way the code
does currently.
The downside of dropping the feature is that it can be hard to get any useful
logging about of the JDBC drivers when you're loading them into an arbitrary
application if you can't dynamically configure logging.
I guess the workaround will be to ask users to re-pack their driver JARs with
their desired log4j2 configuration file if that seems acceptable?
> 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)
