ring
ring copied to clipboard
ring-clojure
Add a way to get a Jetty Server instance without starting it
À la creating an instance of your application without starting it, I'd like to be able to call run-jetty to get an instance of the server, but without the side effect of actually starting it.
Since the function is called run-jetty, it would be odd if it didn't start the server, and it would also break the contract of being an adapter.
Perhaps a better solution is just to have a function that creates a Jetty server, maybe named jetty-server.
There is an existing (private) function create-server.
How about making that function be public, and support a version of run-jetty that would just take a created server and run it? With the argument vector [handler options server]
In line with the Sierra workflow proposal, is it possible to shutdown a running jetty server? If so, it would be nice to have a function to do that too.
Another, less important thought: would it make sense to unify and clean up the naming of these related functions?
Assuming that most people will (:require [ring.adapter.jetty :as jetty]), then having functions jetty/create, jetty/run, jetty/stop might be cleaner.
@dcj Indeed, since run-jetty just returns the Server object. My current solution is essentially (.stop (run-jetty ...)).
@weavejester I don't understand what you mean by "break[ing] the contract of being an adapter" (:confused:), but your solution sounds good.
The run-jetty function needs to be kept around for backward compatibility, and the ring.adapter.jetty namespace must include an adapter function, as defined by the Ring specification.
I don't understand what you mean by "break[ing] the contract of being an adapter"
An adapter is defined by the Ring specification as being a function of two arguments, a handler and a map of options, that starts a HTTP server. If we break this specification, we break compatibility.
So run-jetty can't change, but we can add a new function, such as jetty-server.
@weavejester How about this solution? I'm not sure what tests I could add for this, since run-jetty utilizes jetty-server now and all the existing tests pass.
I think I'd prefer add-handler be just part of jetty-server, and something that's required, not optional.
Well, the idea behind that was that sometimes I won't have a handler until everything starts up. So I'll run some functions that build a handler based on other systems starting up, and only then start the server with the new handler.
Do you think it complicates the API too much?
If you need to wait for the server to start before creating your handler, it might be a better idea to use a placeholder using a var or wrapper function. A server without any handler doesn't make any conceptual sense.
I'm not waiting for the server to start before setting a handler, but I am creating and instance of the (stopped) server before setting the final handler. I have been using a placeholder handler with the current API, then calling the private proxy-handler to generate a Jetty handler from my Ring handler. If that would be preferred over this new solution, I'm okay with that.