0

I've been experimenting with different logging frameworks for use in a Java library I've been developing. I'd like to separate the logging configuration of the library from logging done by users implementing the library. I want users of my library to be able to specify their own LOG2J2 configuration and log their own information without it having ANY effect on the logging configuration of the library. The best way I can see to accomplish this is to have the library create and use it's own LoggerContext. I have two questions: Is it possible to create and use a special LoggerContext specifically for my library or is there perhaps an easier way to accomplish what I'm trying to do? Once I've created a LoggerContext and applied its configuration is it possible to somehow tie it back to the LogManager so that when I call LogManager.getLogger() from my library it will use my custom LoggerContext?

To try and put it simply, I want to separate the framework logging from the implementation logging. Similar to what is being described here. Unfortunately, that link seems to focus more on Web logging separation rather than application/framework logging separation.

Vektor
  • 31
  • 2
  • "I want users of my library to be able to specify their own LOG2J2 configuration and log their own information without it having ANY effect on the logging configuration of the library." So you don't want the user to be able to configure the framework logging at all - if the user wants to disable or filter the framework logging or direct it to another file they are not allowed to do so. Why would you want that? If I were a user I'd be really irritated by that. – D.B. Aug 29 '18 at 04:16
  • You're absolutely right and I understand completely. However, my goal here is not to prevent users from making configuration changes, but rather to make it easier for users to make configuration changes both before and at runtime. My library already has its own "Settings" system for configuring many different subsystems. I'd like to also integrate the logging configuration into this existing "Settings" system to provide a centralized way of configuring the entire library, saving users the trouble of having to modify many different external configuration files, one for each subsystem. – Vektor Aug 29 '18 at 14:39
  • I'd also like to accomplish this without impacting the configuration or functionality of any logging performed by the user. So I'm basically trying to encapsulate the logging system of the framework from the logging system of the users. Enabling users to change or disable logging on the framework using the built-in Settings system without it affecting or disabling their own logging configuration settings. – Vektor Aug 29 '18 at 14:51
  • 1
    Thanks for the clarification. I think if you try to integrate the settings for log4j2 into your own settings system it's going to force you to depend on many aspects of the log4j2 implementation. What happens if a user wants to use a different logging implementation so they add the [Log4j to SLF4J Adapter](https://logging.apache.org/log4j/2.x/log4j-to-slf4j/index.html) to their classpath? Now your settings don't work anymore. I think you would be better off simply documenting the fact that your library is coded to use log4j2 and leave it at that. – D.B. Aug 30 '18 at 04:12
  • The idea was to enable my library to have it's own dependency on Log4J2 with it's own Log4J2 runtime configuration (integrated with the settings class) while also allowing the user to do whatever they wanted as far as logging is concerned without having to worry about the logging implementation used by the library itself. Since there isn't really an easy way to accomplish this I just decided to go back to using SLF4J and just do what everyone else does: shift responsibility to the user, hope they are familiar with SLF4J, and hope they share my definition of each logging level. – Vektor Aug 30 '18 at 20:11
  • Please read [the answer given by Remko Popma](https://stackoverflow.com/a/41500347/3284624) regarding why it's better to code against log4j2's API. Also, if the user doesn't share your definition of the log level they can create their settings to filter out the logs they don't want to see. – D.B. Aug 30 '18 at 22:36
  • I've read it and I'm sure LOG4J2 is better in most cases. I discovered that Java 9 introduced its own logging API and have decided to go with that. I was able to create a logging implementation configurable by the existing Settings system in my library, removing the need for a third party logging dependency altogether. I've spent an inordinate amount of time researching various third party logging facades and their implementations. The Java 9 logging API gave me what I needed and will hopefully save the user from having to deal with the same frustrations that have consumed so much of my time. – Vektor Aug 31 '18 at 04:10

0 Answers0