dimanche 5 mai 2019

What are the best practices for enabling client configurable logging using slf4j in a Java SDK?

I am building an API wrapper over our product, in Java. Currently, for logging in the wrapper, I am using slf4j, binded with log4j, with both of these dependencies in my maven project. I'd like the logging to be configurable, so that the client who uses the wrapper can change to any other binding supported by slf4j. Now, I'd like to know the best way to do this, without embedding any bindings inside my jar.

So far, what I've explored is:

Have just slf4j dependency in my wrapper project and while shipping, give the client a sample configuration file for each of the binding (log4j,log4j2,logback) which exposes the package names and logging levels. The con of this approach is that the developer who's working on adding features to the API wrapper, will have to add a logging implementation dependency in the pom while developing, and remove it before shipping. Moreover, the internal libraries in my api wrapper need some configurations to hide certain logs. I'll have to expose those in my sample configuration files as well, to suppress the logging noise.

The other way is to have a default logging binding (say log4j) inside my API wrapper jar. Now, slf4j won't support multiple bindings on the classpath, so it won't be pluggable for the client, but the problem in the previous approach would be solved. This makes my logging less configurable (in fact, not configurable at all).

What's the preferred way of achieving this?

Thanks in advance!

Aucun commentaire:

Enregistrer un commentaire