How do you set up log4j for a gradle project with modules?


(andrew dingfelder) #1

how do you set up log4j for a gradle project with modules?

I have a project set up like the following:

project root
build.gradle
gradle.properties
settings.gradle
// this root project does:
// include CommonModule
// includeBuild <all composite modules within module folder>

---CommonModule
------build.gradle
------gradle.properties
------settings.gradle
------src/main/groovy/...<common-code>
------src/main/resources/log4j2.xml

Modules
---OtherModule-1 
// this is a gradle composite module
// it also includes the common module 
------build.gradle
------gradle.properties
------settings.gradle
------src/main/groovy/...module1-code
------src/main/resources/log4j2.xml
---OtherModule-2 
// this is a gradle composite module
// it also includes the common module 
------build.gradle
------gradle.properties
------settings.gradle
------src/main/groovy/...module2-code
------src/main/resources/log4j2.xml

As shown above, we have a common gradle module and a module folder that contains module related composite module, each which depends on the included CommonModule (core common code goes in common, the composite modules each contain code that extends common stuff

My question is hopefully simple:

  • where do I configure my log4j module?
  • e.g. can I put it in the common include module ?
  • or does each composite module need to have their own log4j xml?

I asked about this on stackoverflow and got no feedback, figuring this might be a better place to ask


(Trejkaz (pen name)) #2

My own guidelines for this:

  • Common module doesn’t include a log4j config
  • Individual library modules don’t include a log4j config either
  • Top-level application module does include a log4j config, but doesn’t put it on the classpath (I set aside a src/[configuration]/config directory just for that)
  • Launcher for the application itself (whether from a release build or from a JavaExec in the Gradle build) specifies where the log4j config is loaded from, so that you can’t get accidentally poisoned by other configs on the classpath

(andrew dingfelder) #3

thanks, that makes sense