[
https://issues.apache.org/jira/browse/JENA-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17128257#comment-17128257
]
ASF subversion and git services commented on JENA-1912:
-------------------------------------------------------
Commit 5d8f72debde832f81a6d64cbae28f42f7c087be2 in jena's branch
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=5d8f72d ]
JENA-1912: Fix LogCtl and non-Log4J2 provider. Logging cleanup.
> LogCtl.<init> loads Log4j2 code
> -------------------------------
>
> Key: JENA-1912
> URL: https://issues.apache.org/jira/browse/JENA-1912
> Project: Apache Jena
> Issue Type: Bug
> Affects Versions: Jena 3.15.0
> Reporter: Andy Seaborne
> Assignee: Andy Seaborne
> Priority: Major
> Fix For: Jena 3.16.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is a problem in applications that choose to use a different logging
> provider.
> If {{LogCtl}} (a collection of static methods) is even just touched, before
> any static method call, and with org.slf4j:slf4j-jdk14 as logging provider,
> there is an exception:
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/logging/log4j/core/config/ConfigurationFactory
> at dev.ReportLogCtl.main(ReportLogCtl.java:62)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.logging.log4j.core.config.ConfigurationFactory
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> ... 1 more
> {noformat}
> I don't know why {{ConfigurationFactory}} is being loaded. It isn't in a
> static member, only one static method. The same code for log4j1 did not have
> the same problem.
> {{LogCtl}} is not normally used. I came across this in RDF delta where the
> logging provider for testing is JUL andthe test use LogCtl to enable/disable
> loggers during tests.
> Rather than a point fix, the code should be changed:
> # Use whatever mechanism the logging provider has for initialization. (system
> properties usually).
> # Move the provider specifc code to another place so it is not loaded as part
> fo LogCtl class initialization.
> Athe same time, switch to a single {{LogCtl.setLogging}} which installs some
> basic default setup if there isn't the preferred setup for the logging
> provider.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
