Add a way to get a Jetty Server instance without starting it

[mybuddymichael]

À 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.

[weavejester]

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.

[dcj]

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.

[mybuddymichael]

@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.

[weavejester]

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.

[mybuddymichael]

@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.

[weavejester]

I think I'd prefer add-handler be just part of jetty-server, and something that's required, not optional.

[mybuddymichael]

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?

[weavejester]

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.

[mybuddymichael]

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.

[weavejester]

Could you explain your use-case in a little more detail?