-
Notifications
You must be signed in to change notification settings - Fork 100
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
Async handlers work only with Jetty #220
Comments
I'm not sure if this is the only error, but the problem I can see is that you're using |
Hmm fair point, but I would expect a |
Hi there, So, I've abandoned the idea of providing 2 arities, and I've gone with var-args instead which seems to work: (defn generate-handler [project handler-sym]
(if (get-in project [:ring :servlet-path-info?] true)
`(let [handler# ~(generate-resolve handler-sym)]
(fn [req# & args#]
(let [context# (.getContextPath
^javax.servlet.http.HttpServletRequest
(:servlet-request req#))]
(apply handler#
(assoc req#
:context context#
:path-info (-> (:uri req#) (subs (count context#)) not-empty (or "/")))
args#))))
(generate-resolve handler-sym))) I have to admit that I'm not 100% happy with it, but at least it works. Do you want a PR for it, or would you prefer to have a stab at it yourself - see if you can get the 2-arity working? |
I'd rather figure out why it doesn't work, but I'm not going to have any time to investigate for a while. |
Like you, I would love to know why it can't compile the 2-arity fn, but at this point I've run out of ideas and things I can try. My custom fork is at version
|
Is it possible to provide a repository that replicates the error? |
I'll see what I can do...Would a zipped project do, in case I'm not able to publish something online? |
Yes, if you like you can send it directly to my email, [email protected]. Otherwise, if the problem can be replicated with a minimal project, then that would be fine, too. |
There are two issues preventing async handlers from working in any Servlet container, other than Jetty (e.g. Tomcat). Thankfully, one of them is super easy to fix, but the other I'm having trouble with and I would appreciate your help.
The
web.xml
emitted should contain aasync-supported
tag - especially when the[:ring :async?]
option is true. This is very easily fixable by adding[:async-supported (:async? ring-options false)]]
, right before closing the:servlet
tag in themake-web-xml
function (here). If I manage to fix point 2 (see below), I can include this in the PR, otherwise it's such a trivial change that I don't really see the point of a PR just for that.The
compile-listener
function callsgenerate-handler
in order to resolve the actual user handler(here). As you can see if the[:ring :servlet-path-info?]
option is true (or missing), the user-handler is wrapped in another function, which however takes a single argument, and therefore won't work with the three arguments passed to it (per the asyncring.util.servlet/make-service-method
). If the[:ring :servlet-path-info?]
option is explicitly set to false, then it works as expected (assuming of course that the actual handler allows for 3 args). Now, you might be tempted to think that this is also easily fixable, but trust me, it isn't...I tried adding a 3-arg arity to that function returned bygenerate-handler
, and everything compiles/builds/deploys no problem, but then when I try to use it on a real project, I get compile-syntax errors like this:Here is the code in case you have doubts that the syntax is correct:
I also tried generating two distinct functions based on the :
async?
option, but I got the exact same compile errors:If you can provide any form of insight as to why such a simple change (adding an arity) would cause compile-syntax errors, that would be fantastic. Many thanks in advance...
The text was updated successfully, but these errors were encountered: