and let me know if you figure out what happened

What is the purpose of wrap-context in middleware.clj? I see it sets the :servlet-context key of the params map used to render in layout.clj, which if I’ve understood correctly will adjust any links to from /foo/bar to /context/foo/bar. But if I’m right, what is the reason for using a dynamic binding to do this?

@alexchalk17 there are two use cases for this, one is if you're running inside an app server like jboss, where the context is provided at runtime, the other is if you decide to front multiple apps on the same domain with nginx or something

and you don't need it to be dynamic in that case

@yogthos, I’m still not sure I get it—in the jboss example, what stops you from querying the application context directly in layout.clj? Does it change during runtime?

It doesn't, but all the routes have to use the prefix, it just the layout ones

in my template *app-context* is only used in layout.clj?

is it because in the jboss scenario you can’t define *app-context* in the render logic without passing in http request info? so the dynamic binding is a neater way of letting the rendering logic access a definition made in another part of the application?

yeah basically

it allows specifying the context via the middleware, and then accessing that context wherever it's needed

it might be better to just stick it as a key on the request though, that logic has been there for a while, and I haven't used it myself in ages

I'll take a look at getting rid of the dynamic var, those are always a bit of a smell 🙂

although then you would have to pass the request to the render function in layout for all requests

thanks @yogthos, that makes sense now. I’m still pretty new to clojure, and discovering dynamic vars was a bit of a wtf moment 😛, but I agree that it is more elegant than always passing the req to the render function.

@alexchalk17 👍

it looks like the whole app server idea is going away anyways now that containers are popular, if you're making a green field project then it's much better to just have a jvm per app in my opinion

especially now that jdk 10 plays nice with containers 🙂