As I've been looking at this patch, I've been thinking of a few problems.
1) The @Service(Object.class) and @Property(name="javax.ws.rs", boolValue=true)
IMO, this feels a bit of a hack.
2) The shared container provides some potentially undesirable behavior.
If I have two different bundles, each providing some Resources and each providing some Providers, one bundle's providers can be used by another bundle. For example, I have two resources that produce text/html, bundle A provides a MessageBodyWriter for text/html, and bundle B does not. Is it intentional that bundle B can use the writer from bundle A if bundle A is started and active? Should bundle B provide it's own implementation? What happens if they both provide writers for text/html.
If two bundles have overlapping Resources, what would the intended behavior be? I can't clearly figure it out.
If bundle A provides an exception mapper, say for a resource not found, and it is evaluated first, would it fall through to bundle B? Should it?
3) Adding the @Service annotation indicates a singleton class, but this is contrary to JaxRS, where a resource is only a singleton if it's annotated with @Singleton
Additionally, I don't see support for a non-singleton class.
4) I'm not a big fan of the servlet listening on any specific URI. I think it is indicative of non-sling like behavior, and results in difficulty figuring out who is handling which URIs. If my bundle listens on /, provides an exception mapper for resource not found, who's resource mapper is more important? Mine or slings?
As I've been thinking about the problem space, I've been thinking of a solution that looks like this:
A) A specific sling node, in the tree, that defines all attributes of a jax-rs container. This includes, a list of resources, providers, exception mappers, features, etc..
B) The jaxrs container is life-cycled with the bundle that it refers to, so if that bundle is offline, so is the container.
C) The sling uri to the container is the root context of the bridge between sling and jaxrs.
This resolves (1) as the resources, providers, etc are explicitly defined in the sling node.
This resolves (2) as each container is isolated from each other container.
This resolves (3) as the container itself builds the classes referred to and can maintain it's own isolation and lifecycle.
This resolves (4) as you must define a sling path to a given set of resources. From there the tree to the individual resources is obscured, but the root context is not obscured.