@mruzicka OK, I think that I see what happened.  In the previous version, we were using the rack webserver service as a replacement for the normal jetty webserver service... but we can't do that now because it needs a different protocol, and other apps that were depending on the original protocol wouldn't be able to find it.

Hrm.  This seems like a good reason for us to consider allowing TK services to implement multiple protocols in the long run.

In the interim, it seems like if you were simply able to get your hands on the service context for the webserver service from the Rack service, we wouldn't need to make the API include anything Jetty-specific.

So, e.g., maybe in the jetty service we add a new function to the protocol that looks something like this:

```clj
(webserver-context [this])
```

And then we implement it using the `service-context` function of the `Service` protocol:

https://github.com/puppetlabs/trapperkeeper/blob/master/src/puppetlabs/trapperkeeper/services.clj#L26

As per the example for `foo3` here:

https://github.com/puppetlabs/trapperkeeper#example-service

So the implementation might be as simple as:

```clj
(webserver-context [this] (service-context this))
```

Then, the ruby service could specify a dependency on that function, grab the `:handlers` object out of it, and add the rack handler?

This would still have the implication that the Jetty-based Rack service must always be used in combination with the Jetty-based Webserver service, but it would prevent the protocol for the main Webserver service from having to leak any Jetty-specific classes.

This is just an idea, let me know what you think.  I'm definitely happy to discuss other ideas!