Glad you could find a solution you are happy with. Note in my suggestion, that the user would change the included file, not the "main" logback.xml file located within the jar. On 3/31/2017 4:21 AM, Rolf Schumacher wrote:
Thank you for your reply, Ceki.
David gave the answer that where useful for my use-case.
You see, when the logback.xml file is hidden in a jar file, it is not easy for an end-user to change it.
--- Viele Grüße, Best Regards
Rolf Schumacher
Am 31.03.2017 07:05, schrieb Ceki Gulcu:
Hi Rolf,
Logback will reload logback.xml if detects that the file has changed. Configuration files can be included [1] and change detection applies to included files as well.
You can instruct the user to create/modify the included config file.
Let us know if it works for you.
-- Ceki
[1] https://logback.qos.ch/manual/configuration.html#fileInclusion
On 3/30/2017 12:54 PM, Rolf Schumacher wrote:
Just started with logback, I made to get work for me.
I am used to distribute my Java software as one jar file and a folder "lib/" holding all jars the executable jar depends on. The executable jar specifies the classpath to lib/*.
Currently the logback configuration file logback.xml is also covered in the executable jar and is recognized by the application.
In case of an issue report from a user, I would like to give the user some instructions to switch to DEBUG loglevel and send me the logging output.
What would be the best way to do so?
Please note that the classpath is determined by the executable jar. I tried to find a way to put a logback-test.xml on the classpath without rebuilding the application. Unfortunately without success.
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user