Yeah, that makes sense.

One other thought...  What if we had the Jetty service go ahead and create the Jetty Server object during its `init` and add the object to the service context -- like what is done with the handlers by `create-handlers` already -- but just not configure the Server object -- e.g., not configure SSL settings -- until the `start` phase?  With this approach, the `add-proxy-route` calls could pull the reference to the Jetty Server object back out of the context and inject it into the `ProxyServlet` instance.  The `netHttpClient` method in the `ProxyServlet` instance could pull the SslContext out of the Jetty Server, which should be realized by the time Jetty would need to call it in order to create the proxy.

I had been hoping that the `ProxyServlet` could get access to the Server object of the servlet container which is hosting it.  Maybe this is available through a parameter on the servlet context but I haven't been able to narrow that down any further.

Also, maybe the SslContext could be cached during execution of the `ProxyServlet`'s init method if it proves to be expensive to pull this in for every request which needs to be proxied.  Not sure if we're guaranteed that the servlet's init method wouldn't be called until after the servlet container had been initialized with all of the needed SSL parameters?