Automatic code reloading is one step behind #78
2 participants
Please open issues on https://github.com/ring-clojure/ring. That is now the canonical Ring repository.
Regarding wrap-reload, which version of Ring are you using?
When using wrap-reload, you need to ensure that the handler is passed as a var to the adapter, otherwise reloading will not have an effect on the running code. However, I'm not sure what would cause the issue of wrap-reload being "one step behind", unless you're not using an up-to-date version of RIng.
haha, oops, this stupid repo always comes up first in the google search results, I must have
mindlessly clicked on issues without looking.
In regards to your comments,
(run-jetty (wrap-reload #'handler)) ; Works
(def handler (wrap-reload some-other-handler))
(run-jetty #'handler) ; Is one step behind, because even though the handler is reloaded the new one won't be used until next request...This simplest fix is just to document this? Otherwise one could add and argument like:
(def handler (wrap-reload some-other-handler #'handler))and have wrap-reload recursively call that var if it does find new
code that needs reloading. Which would be the up to date handler
after a reload.
Which version of Ring are you using? There is a bug in the wrap-reload middleware in previous versions of Ring that can cause an issue like this. Knowing the version of Ring you're using will help eliminate this possibility.
In wrap-reload after the new code is loaded, the old handler is still used to serve
the current request meaning that to see any code changes you have to refresh the page
twice which is seriously annoying.
wrap-reload probably needs to be passed in a var containing the top level application
handler, so that if code is reloaded it can be dereferenced and used to server this
current request.