You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently a configuration file for log4j2 is provided at:
./src/main/resources/log4j2.xml
This file is packaged up and bundled with the rest of the library. That means that any project that uses this application will have that log4j2.xml config file in their classpath.
Since most applications will want to provide their own logging implementations and configuration, it doesn't make sense for a library to be providing the log4j2.xml config file.
This problem is also present for an older version of simple-java-mail that included log4j.properties. This overrode the sandboxed log4j configuration that was provided by the system that ran my application if I was running from a debugger.
This stackoverflow post talks about this issue in the comments:
Ok, so would you agree that it is harmless to provide logj properties or xml if it targets specific library packages? Because I was actually considering packaging 'sensible' default configurations for all major logging implementations and then let users override it with their own configuration.
I think the idea with libraries is generally that they can leverage slf4j or some other logging facade so that they don't need to provide any other logging dependencies.
The user of the library just includes the correct slf4j connector and configure their own logging as they need. If they need special logging levels from a library, they can just enable that in their local configuration file by enabling them for the package path for the classes in that library.
Sample log configurations could be provided, but I don't think that most people would use them. I definitely don't think they should be included in the standard packaging of the library.
A little bit of stackoverflow wisdom on this issue:
Currently a configuration file for log4j2 is provided at:
./src/main/resources/log4j2.xml
This file is packaged up and bundled with the rest of the library. That means that any project that uses this application will have that log4j2.xml config file in their classpath.
Since most applications will want to provide their own logging implementations and configuration, it doesn't make sense for a library to be providing the log4j2.xml config file.
This problem is also present for an older version of simple-java-mail that included log4j.properties. This overrode the sandboxed log4j configuration that was provided by the system that ran my application if I was running from a debugger.
This stackoverflow post talks about this issue in the comments:
http://stackoverflow.com/a/5081386/622115
Thanks,
James
The text was updated successfully, but these errors were encountered: