@len luminus will add a shutdown hook by default in the core namespace in the start-app function:

(.addShutdownHook (Runtime/getRuntime) (Thread. stop-app))

this causes stop-app to be called on shutdown, and you can add stuff there to be run on shutdown

@yogthos thanks I see the code there. Will that wait for any in progress request to finish before closing down ?

I see that the docs refer to using logback in luminus as the logging provider but I dont see the dependency in the project, am I missing something or must I add it explicitly ?

@len it will try to wait, for tasks to finish when shutdown gracefully, e.g. not using something like kill -9. The logback dependency comes from Immutant, so it doesn’t have to be added explicitly.

@len @yogthos I usually add every dependency, that I use (require) in my project explicitly in my project.clj file. Relying to indirect dependencies can lead to all kinds of problems.

I’ve actually rarely had problems with that, and that is the way you’re meant to use maven style dependencies

Thanks @yogthos I discovered lein deps :tree

yeah I was just going to mention that

I was including immutant scheduler and it also has a dep on logback so I excluded it for that dep, the exclusion seemed to be general though and excluded logback all together

I started trying to get rid of some multplie SLF4J warnings 🙁

you shouldn’t have to add exclusions unless they conflict with something

yeah I see that now

lein will typically do a good job resolving that for you, so you can stick to top level dependencies in most cases

I find when you get conflicts it’s usually when a library depends on an outdated version of another library that had an api change

I have had that in plain java projects yes

Indeed, it does not happen often that you run into problems with transitive dependencies, but it can and if it happens it might be hard to track down. Imagine a logging dependency which is brought in by two different dependencies transitively. And imagine on your build system you have a different leiningen version running than on your dev / staging system which finally leads to resolving the logger to two different versions. The working one on your test system and the broken one (define broken yourself) on the production system and then some customer comes and wants to see the log for whatever legal reason and hups, just that day you introduced the bug by not explicitly adding dependencies. Yes, this is very rarely to happen, but this scenario and similar ones will happen. So the question for me is the effort / payoff question. The effort of declaring explicitly is very very low while the payoff is high. This is a low risk / high win situation where I am not even starting to think about doing it differently. Also, you have other gains like explicitly upgrading your dependency, being able to look at the project file and telling which libraries you are using. Especially which version you are using by taking one look.