Clojurians Log v2

Hi all, does anyone know how Immutant the Deuce does Clojure runtime/app isolation? Is it still the same or comparable to http://immutant.org/news/2012/05/18/runtime-isolation/?

arnout: Immutant 2 from an uberjar does no isolation at all, since you can only run one app from the uberjar. If you deploy those apps to a WildFly container, however, you will have isolation between the apps

Each container having there own Clojure runtime?

in WildFly, each app will have its own clojure runtime, yes

Ok, thanks @tcrawley !

my pleasure!

@ddellacosta: howdy! I commented on https://issues.jboss.org/browse/IMMUTANT-610, but am happy to discuss it here

@jcrossley3: ^

@tcrawley: i concur with your proposed fix. worth submitting a patch to @weavejester ?

yeah

@tcrawley I suppose that solution would work. Note that this also affects compojure (https://github.com/weavejester/compojure/blob/6cbc8a95a3d6fc0d3f4b98130db92ff89b8176f0/src/compojure/core.clj#L213-L214) but if I understand what you are proposing, the way :path-info is extracted in compojure also uses the :url value as a fallback so should work. I guess what makes me nervous is that this behavior is not very explicit. Seems to me that regardless of whether ring is patched or not, it would be useful to make this explicit in the undertow configuration in immutant.

the reason why undertow decodes the path-info is that it's mandated by the servlet spec

oh no, I guess the compojure bit would have to be patched separately

jetty does it as well, but the ring-jetty-adapter doesn't stick the :path-info in the request

oh yeah—to be clear, I’m more proposing (as one alternative) that DECODE_URL is described in the undertow options in immutant, not necessarily that it should be changed by default

I mean, I still think you’re right, seems like ring/compojure shouldn’t be doing what they’re doing

I'm not opposed to exposing it as an option, but my concern is setting it will cause that app to then potentially fail if it's deployed to WildFly

especially if decoding of the path is mandated by the spec—seems like ring/compojure is doing the wrong thing here

yeah, I can see your argument

well, I’m happy to help offer a patch for both. Does it make sense, furthermore, that jetty behave differently here? I guess one point I’m confused on is why jetty doesn’t store this information in the ring request

looking at that compojure code - is path even used?

the reason the jetty adapter doesn't set :path-info is because it was never used to host apps anywhere other than the root context (/). :path-info support in ring came about from people trying to run apps as wars in containers or when using Immutant 1, so it's kinda an afterthought

the path-info is definitely used in params in compojure, and that’s how I found this issue in the first place

I think if compojure does need path-info, it should be modified to use request/path-info, once it is fixed to decode the uri

that seems reasonable

and I believe that it would have to be using :path-info somewhere, I just don't see it in the code you linked is all

I'd be happy to file an issue with ring, or support you if you want to do it

re: path-info getting used in compojure, it’s actually another layer of indirection—the clout function route-matches splits up the path-info and then returns it as params (https://github.com/weavejester/clout/blob/5b943e7d04279f40dd743800478c486e164593fd/src/clout/core.clj#L46), where it then gets decoded

anyways, let me read through this a bit more

I still don’t like how this is all under the covers, in ring and compojure at least