2

I would like to deliver jar files with its own logback logging configuration. The common way to configure logback is with the default file logback.xml that logback library reads from the classpath's root (works for application servers or not).

You could include another files from the main logback config file (didn't try it), but I don't know which jars will be in the classpath and which ones require the log configuration.

Plus, the jars could be used in a command line application or application servers (shared library or not).

I thought that maybe I could get the filepath to the jar and check if there is a config file there, and try to read the configuration programmatically and load it with JoranConfigurator.

// This is the way I find to get the path to the jar
String path = ClassThatWantsALogger.class.getProtectionDomain().getCodeSource()
            .getLocation().getPath();
String decodedPath = URLDecoder.decode(path, "UTF-8");// the path to the jar

But this approach could fail because depends on the security restrictions, maybe fails in Linux or in application servers. It's a hard approach for a problem that probably has a better solution.

Do you imagine a way to manage that jars could have its own logback config file that works for any environment?

Pedro
  • 692
  • 8
  • 24
Jonathan Barbero
  • 2,504
  • 1
  • 26
  • 47

1 Answers1

2

I will cite myself to answer your question: Logging configuration is the concern (separation of concerns) of the client application. It's his decision to make where, how and what will be logged. You shall not impose anything on it by our library.

Community
  • 1
  • 1
Michael-O
  • 18,123
  • 6
  • 55
  • 121
  • 5
    In the organization where I work, I have to provide libraries to other teams with common functionality and connectors to other applications. It's my concern to decide where and what it's going to log these libraries. If I had to ask to these teams that they must add specific config in their logback config file they could make a mistake and forget or misconfig what I request. Plus, if I want to change the log config of these libraries I need to request to these teams to change the logback config file. Plus, they usually don't have access to modify this in production enviroment. – Jonathan Barbero May 15 '12 at 15:29
  • 4
    Providing libraries is fine, this is what I do too. How can that be your concern if you code general libraries where you are unaware of the target environment? I am sorry to tell you this, but your company's concept is just ill-conceived. This is not the way logging configuration is intended. All you can do is provide a conf file in `com/company/package/logback.xml` and include that file in the target environment with ``. – Michael-O May 15 '12 at 17:42