I have a maven project with several dependencies and use log4j.properties to control output. In some cases the same class may be referenced in different property files with different parameters. Is there a defined protocol for “overriding” properties or does it depend on the order in which packages are loaded?
(I am locating all log4j.properties directly under src/main/resources – is this the correct place?)
UPDATE:
I have accepted @Assen’s answer as it makes sense though it doesn’t make the solution easy. Essentially he recommends excluding log4j.properties from the jar. In principle I agree, but it puts the burden on the user to control the output and most of my users don’t know what Java is, let alone properties files.
Maybe there is a way of renaming the properties files in each jar and using a switch (maybe with -D) to activates the properties.
I often have similar discussions on projects. I thing log4j.properties is typically something you want to keep out of the application, and not pack it in a war and deliver it together with the code. Logging configuration:
Why package logging configuration together with your code then? I usually keep somewhere a configuration folder, with soubfolders like ‘dev’, ‘test-server-01’, ‘macbook-john’ etc. Each subfolder contains list own copy of log4j.properties. None of them is included in the build artifact – jar or war.
When deploying, one of thuse subfolders is delivered separately. For the test server 1, this would be the content of test-server-01 subfolder. Dependng on the application server used, thers is a different trick tu put some files on the classpath.
When developing, I take care to set one of those subfolders on the path. When John develops on his macbook, he might want to put ‘macbook-jihn’ on the classpath, or create a new one. He can change logging settings and commit without conflicts.