-
Notifications
You must be signed in to change notification settings - Fork 485
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
Archaius 2 should have its own pluggable logging #426
Comments
I am not sure I am understanding the issue here. Do you have a use case where you would like to swap out the actual logging binding at runtime based on configuration information? If so what does that look like? Otherwise it seems like having logging in the core is pretty valuable. |
Not the logging binding but the configuration. For example lets say you are publishing messages to Kafka or RabbitMQ (e.g. an Appender that needs config) you need the configuration of that server information. In some cases we use LogBack and some cases we use legacy Log4J. The most reliable way to configure both of these is through System Properties. Consequently when are apps boots up it loads properties and will set some System Properties before anything else gets loaded (passing system properties on the command line is insecure). And this isn't just for logging as some legacy libraries use System Properties (this is because there isn't a standard way to get configuration like there is for logging (e.g. SLF4J or java.util.logging). SLF4J offers no way to intercept the binding. It is static and allows no hooks. I have ranted about this annoyance for some time (http://mailman.qos.ch/pipermail/logback-user/2016-June/004781.html). Regardless even if SLF4J did support interception there are many high performance libraries and applications that prefer not do any initialization of logging but still would like some way to do configuration (otherwise we are back to System.properties). Initialization is so slow for Logback I pushed for Ceki to add a Service Loader implementation (qos-ch/logback#181). Reinitializing logging is even more detrimental and fairly unreliable (dropwizard has had many issues with this IIRC). Luckily the API does zero logging so for now we can just fork archaius2-core. Other more sophisticated components (e.g. Hibernate, Spring or even other more complicated archaius components) using SLF4j I acceptable because initialization of core configuration is done by then. |
Also Typesafe config does zero logging so clearly a configuration framework can be written with out needing logging. |
One of the reasons why my company has not switched over to Archaius 2 is that Archaius 2 core uses SLF4J (we have our own internal config library that I need to finish open sourcing).
The inherent problem of using SLF4J in a configuration library is that you now really can't use the library to configure any logging. The static binding nature of SLF4J further exacerbates this. Of course one solution would be to reinitialize the logging framework as a sort of two phase approach but this is not ideal particularly since even modern logging frameworks (e.g. logback) have issues at times with reinitialization.
It would be ideal if Archaius 2 allowed a simple SPI for plugging in custom logging (perhaps through the Service Loader mechanism). I know this sort of defeats the purpose of SLF4J but this library is sort of a fringe case and I think configuration bootup should happen before logging framework initialization.
An optional default would be to use JUL directly. Yes JUL is nasty but for bootstrap logging it is not so bad.
The text was updated successfully, but these errors were encountered: