So, the issue with pulling the SSLContextFactory off of the server object is that our API makes a different assumption about the cardinality there than Jetty itself does.  In particular, Jetty associates the SSLContextFactory with a connector object, and the Server can have any number of these.  (In the future, I can even imagine us leveraging this to allow you to open up multiple sockets with different handlers attached to them.)

So, I *could* do what you are suggesting, but I'd have to iterate over the connectors that I find on the Server object looking for one that happens to be SSL, and then assume that that one is the right one for me to grab the ContextFactory from.  I don't necessarily mind changing it to do that if we think it's better, but it made me a little nervous because it's basically a heuristic, whereas the current approach is explicit and concrete.

With regards to the second part of your comment, can you clarify a bit what it is that you're worried about being expensive?  Atoms don't involve locking for read operations, and since we're effectively caching the SSLContextFactory in either code path (either when Jetty starts, or during add-proxy-route if they specified their own pem paths), I'm not 100% sure I understand where additional caching would improve things?  Is it just the atom dereference that you're worried about?