Closed gidxl03 closed 4 years ago
I would forgo the advice in Log4j's docs as well as Pivotal GemFire's docs, that I referenced in #18, and follow this instead.
As SBDG's documentation on logging states, logging completely changes in Apache Geode 1.9.2
(which equates to Pivotal GemFire 9.8.x
). For instance, setting the gemfire.log-level
property no longer has any effect. In fact, this is exactly what SDG's @EnableLogging
annotation does under-the-hood when you explicitly annotate your Spring Boot application class or @Configuration
class with @EnableLogging
. Of course, you don't need to explicitly configure Logging with a property or SDG's @EnabeLogging
annotation since SBDG auto-configures logging for you, providing you declared the right dependencies on the application classpath to begin with.
Essentially, I would do the following:
For instance, when using SLF4J and Logback, this would be a logback.xml
file placed in the root of your application classpath (e.g. in src/main/resources
). When the log configuration file is placed in src/main/resources
it will be packaged with your Spring Boot application at the root of the application classpath in the JAR file.
org.springframework.boot:spring-boot-starter-logging
or ideally, the (relatively) new org.springfamework.geode:spring-geode-starter-logging
dependency on your application's runtime classpath.I have an example of this configuration arrangement in the SBDG codebase, specifically in the examples that are used in the reference documentation. For instance, see the logback.xml
file. I then declared the org.springframework.geode:spring-geode-starter-logging
dependency in my Gradle build file. This is not unlike how it would look/be in your application.
When I set the org.apache
Logger to INFO, I indeed see log output from Geode (not just the app) when I run 1 of the documentation example classes , for instance.
Also, I am curious what (logging) dependencies is on application classpath?
For example, if you had GemFire/Geode's own geode-log4j
dependency on your application classpath, either directly or transitively, this may be causing some sort of conflict, though I am not for sure.
Keep in mind, that geode-log4j
typically must be explicitly declared, although could be pulled in transitively if you are using some other feature of GemFire/Geode the requires it, and this module uses Log4j as the logging provider and provides a default, Log4j XML file.
Anyway, I cannot say for certain since I actually have not tried your approach above.
So, let's start with the information I provided above and then go from there after you have had a chancel to review/experiment.
Cheers!
Given we have not received feedback on this Issue since June 4th, 2020, I am closing this ticket.
If you are still experiencing problems or have additional questions, please re-open this ticket.
As a follow on to https://github.com/spring-projects/spring-boot-data-geode/issues/18 where the solution to stop geode from overriding log4j configuration was to set
my issue is that I specify my log4j config using the method described in https://logging.apache.org/log4j/2.x/log4j-spring-cloud-config/log4j-spring-cloud-config-client/index.html where bootstrap.yml contains
then my app logs normally during bootstrap until it reaches what I suspect is a Geode lib and logs "GemFire-Source-Repository:support/9.1" after which point my Spring Config server's logging configuration is ignored.
I can workaround this issue by setting -Dlog4j.configurationFile=junk and ignore ERROR StatusLogger File not found in file system or classpath: junk
Is there a better way? Many thanks.