Skip to content
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

remove tools.logging dependency #15

Closed
tolitius opened this issue Nov 23, 2015 · 1 comment
Closed

remove tools.logging dependency #15

tolitius opened this issue Nov 23, 2015 · 1 comment

Comments

@tolitius
Copy link
Owner

Logging Choice

There are logging alternatives such as unilog or timbre, and mount should not bring tools.logging with it: while it can be excluded, it's just an extra step that should be avoided.

Visual Help

The way mount currently logging states while bringing them up and down is quite helpful to resolve any exceptions during start/stop/suspend/resume, since it is visible which state caused it:

22:13:06.591 [nREPL-worker-0] INFO  mount.core - >> starting..  app-config
22:13:06.592 [nREPL-worker-0] INFO  mount.core - >> starting..  conn
22:13:06.767 [nREPL-worker-0] INFO  mount.core - >> starting..  web-server

BindException Address already in use  java.net.PlainSocketImpl.socketBind (PlainSocketImpl.java:-2)

so it is obvious that the answer to the problem is in starting.. web-server.

Exception Details

On the other hand, mount adds details to the exception to make is clear when/where it occurred. For example if the above exception is looked at in REPL *e, it would have the details about web-server:

#error {
 :cause "Address already in use"
 :via
 [{:type java.lang.RuntimeException
   :message "could not start [web-server] due to"                 <<<<<<<<<<<<<<
   :at [mount.core$up$fn__4959 invoke "core.clj" 55]}
  {:type java.net.BindException
   :message "Address already in use"
   :at [java.net.PlainSocketImpl socketBind "PlainSocketImpl.java" -2]}]
 :trace
 [[java.net.PlainSocketImpl socketBind "PlainSocketImpl.java" -2]
  [java.net.AbstractPlainSocketImpl bind "AbstractPlainSocketImpl.java" 382]

Therefore I believe it is safe to remove mount logging all together.

Needs Thinking

If logging is removed, and there are no exceptions during start/stop, it is not obvious which states have started / stopped / suspended / resumed.

Feels like all lifecycle functions need to simply either return all the states that they changed OR return the current app status:

({:name conn, :started? true, :suspended? false}
 {:name nrepl, :started? true, :suspended? false}
 {:name q-listener, :started? true}
 {:name web-server, :started? false}
 {:name test-conn, :started? false}
 {:name test-nrepl, :started? false}
 {:name app-config, :started? true, :suspended? false})

With simply returning a set of states a particular lifecycle method affected, there is a caveat: start can also resume.

tolitius added a commit that referenced this issue Nov 23, 2015
start/stop/suspend/resume would not return all the states they effected/touched
tolitius added a commit that referenced this issue Nov 23, 2015
start/stop/suspend/resume would now return all the states they effected/touched
tolitius added a commit that referenced this issue Nov 23, 2015
as part of minimizing library dependencies, removing clojure.tools.logging
not to force it on mount clients
@tolitius
Copy link
Owner Author

mount now returns all the states that were changed by start/stop/suspend/resume:

dev=> (mount/start)
{:started [#'app.config/app-config 
           #'app.nyse/conn 
           #'app/nrepl
           #'check.suspend-resume-test/web-server
           #'check.suspend-resume-test/q-listener]}
dev=> (mount/suspend)
{:suspended [#'check.suspend-resume-test/web-server
             #'check.suspend-resume-test/q-listener]}
dev=> (mount/start)
{:started [#'check.suspend-resume-test/web-server
           #'check.suspend-resume-test/q-listener]}

the interesting bit here is vector vs. set: all the states are returned in order they were changed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant