[
https://issues.apache.org/jira/browse/GEODE-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448967#comment-16448967
]
John Blum commented on GEODE-5001:
----------------------------------
Hmm, [LOG4J2-2152|https://issues.apache.org/jira/browse/LOG4J2-2152] is a
rather interesting (yet, ambiguous) problem. There is so much redirection
(Java Util Logging (JUL), Tomcat JULI, SLF4J, Lo4j2), that it makes me wonder a
few things...
1) Is this perhaps a Tomcat Java ClassLoader isolation problem and not a Log4j
problem, especially since there is mention of multiple instances of the same
Webapp (different configurations)?
This might explain why Log4j's {{EnvironmentPropertySource}} is not of the
Log4j type, {{PropertySource}}, even if the Log4j JARs were arranged in the
Tomcat common (shared) lib directory, since each Webapp, to enforce isolation,
would have it's own ClassLoader. Are the logging libs (perhaps) shared?
2) There is a lot of "bridging" going on in the _Stack Trace_ noted in
[LOG4J2-2152]. This...
{code:java}
...
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:122)
...
at
org.slf4j.bridge.SLF4JBridgeHandler.getSLF4JLogger(SLF4JBridgeHandler.java:202)
at org.slf4j.bridge.SLF4JBridgeHandler.publish(SLF4JBridgeHandler.java:293)
...
at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:180)
at org.apache.juli.logging.DirectJDKLog.info(DirectJDKLog.java:123)
{code}
... suggests, based on the [SLF4J legacy|https://www.slf4j.org/legacy.html] doc
that the user is routing all logging events to (indirectly) Log4J2 as the
logging "provider", i.e. Tomcat JULI/JUL -> SLF4J -> Log4j.
So, from JUL to SLF4J using {{jul-to-slf4j.jar}}, and from SLF4J to Log4j using
{{slf4j-log4j12.jar}.
What if *Log4j* were not used as the "_logging provider_", actually, and
instead use _Logback classic_ along with routing all Log4j logging events to
SLF4J using {{log4j-over-slf4j}}?
3) Perhaps a different {{PropertySource}} may workaround the problem?
So, rather than an {{EnvironmentPropertySource}} (seemingly, a global
configuration {{PropertySource}}) would another {{PropertySource}} type (e.g.
[{{PropertiesFilePropertySource}}|http://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/util/PropertyFilePropertySource.html])
exhibit the same problem.
4) What does [LOG4J2-2152|https://issues.apache.org/jira/browse/LOG4J2-2152] in
particular have to do with upgrading Apache Geode to a newer version of Log4j?
LOG4J-21512 only seems to happen if 1) the same Webapp (differing only
configuration) is deployed multiple times to Tomcat, and 2) when all logging
events are routed to Log4j.
E.g. is there concern with the embedded Apache Geode services (e.g.
Management/Developer REST APIs, Pulse, etc), which to my understanding, are now
back to running on Eclipse Jetty?
> Update logj4 dependency to better integrate with Spring
> -------------------------------------------------------
>
> Key: GEODE-5001
> URL: https://issues.apache.org/jira/browse/GEODE-5001
> Project: Geode
> Issue Type: Improvement
> Components: build, logging
> Reporter: Anthony Baker
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The current geode log4j dependency is v2.8.2. Spring (Boot, Data, etc) use
> log4j v2.11.0. This make integration challenging. We should upgrade our
> dependency to match Spring. This will make it easier for our users to write
> geode applications.
> Checking for other updates using
> {noformat}
> gradle dependencyUpdates
> find . -name report.txt | xargs grep -e "\]$" | grep -v "org.apache.geode" |
> tr -s " " | cut -d' ' -f3- | sort | uniq | less
> {noformat}
> show that we have some other libraries that can be updated as well:
> {noformat}
> com.fasterxml.jackson.core:jackson-annotations [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.core:jackson-core [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.core:jackson-databind [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.module:jackson-module-scala_2.10 [2.9.4 -> 2.9.5]
> com.google.guava:guava [24.0-jre -> 24.1-jre]
> com.google.protobuf:protoc [3.5.1 -> 3.5.1-1]
> com.zaxxer:HikariCP [2.7.6 -> 3.0.0]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
