Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

log4j configuration is being supplied with the library #45

Closed
james-m-henderson opened this issue Jun 24, 2016 · 3 comments
Closed

log4j configuration is being supplied with the library #45

james-m-henderson opened this issue Jun 24, 2016 · 3 comments

Comments

@james-m-henderson
Copy link

james-m-henderson commented Jun 24, 2016

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

@bbottema
Copy link
Owner

bbottema commented Jun 25, 2016

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.

What do you think?

@james-m-henderson
Copy link
Author

james-m-henderson commented Jun 26, 2016

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:

https://stackoverflow.com/questions/31138140/should-i-put-log4j-properties-file-into-library

http://stackoverflow.com/a/5081386/622115 (check the comments).

@bbottema
Copy link
Owner

bbottema commented Jun 27, 2016

Agreed. I'll exclude the config files from the distributions.

I made everything related to logging test-scoped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants