-
Notifications
You must be signed in to change notification settings - Fork 47
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
µ/log and µ/trace should accept a logger #121
Comments
Hi, It is possible to create separate loggers and use them independently if you use the log function In practice, this is not convenient at all, as you have to propagate down the current logger in every single function that might want to use it. The recommended approach is to use just one logger and then have two publishers that will publish only the events on the subsystem you want. ;; add the system as a key-value pair or local-context
(μ/log :order-completed, :system :myapp/system-A, :order-id order-id )
;; start independent publishers
(u/start-publisher!
{:type :simple-file
:filename "/tmp/mulog/system-A-events.log"
:transform
(fn [events]
(filter #(= (:system %) :myapp/system-A)) events))})
(u/start-publisher!
{:type :simple-file
:filename "/tmp/mulog/system-B-events.log"
:transform
(fn [events]
(filter #(= (:system %) :myapp/system-B)) events))}) The value Anyway, I will keep this ticket open, and evaluate if it is worthy to extend the logging macros to accept the logger explicitly. |
Thanks for the assessment -I agree with it without exception. I will add that in my practice, it's common to have development and test systems running concurrently -and even occasionally a production system (particularly if one is not diligently shutting them down). Having all the log statements include a differentiating key/value combo and the configured publishers filter on that would be annoying and further diverge production from test/development. I am soundly opposed to having the running subsystems (everything that logs and the publishers) be aware of what system they are running in. My current solution is to use a wrapper around |
I occasionally have two independent "systems" operating concurrently in one JVM. I have found that mulog events from system A will randomly appear in the output of the publisher of system B and vice-versa. This is the inevitable problem with the stateful log buffer being held in a global (dynamic) var.
With careful use of
binding
andbound-fn
it might be possible to overcome this problem but the generally accepted standard for Clojure libs and SPIs is to at least allow for explicit configuration and to only fall back to global mutable state when explicit stateful parameters are not supplied. This appears to have been taken into consideration in thestart-publisher!
function which has an arity to explicitly supply the buffer to be published.Would it be possible for mulog to expose an explicit interface to
log
that does not rely on global mutable state?The text was updated successfully, but these errors were encountered: