spring-projects / spring-boot-data-geode

Spring Boot support for Apache Geode and VMware GemFire
https://projects.spring.io/spring-boot
Apache License 2.0
46 stars 49 forks source link

Geode overrides bootstrap.yml logging.config with embedded log4j2.xml #87

Closed gidxl03 closed 4 years ago

gidxl03 commented 4 years ago

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

-Dlog4j.configurationFile=location-of-your-file

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

logging:
  config: https://spring-configuration-server.mycorp.com/myApp/default/${logging.label}/log4j2-dev.xml

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.

jxblum commented 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:

  1. Create a logging provider configuration file with log configuration required by your Spring Boot application.

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.

  1. Then simply declare either the 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!

jxblum commented 4 years ago

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.