Tobias Hofer wrote:
> I'm involved in realizing a JAX-RS implementation for the OSGi Service
> Platform. But there are some barriers in the current JAX-RS
> Specification that hinders a seamless integration.
>
The problem is OSGi isn't mature enough to work with modern
user-friendly component models. Keying everything off of an interface
is just a poor model that only works with a small subset of applications.
> One of them is the lack of a root resource service interface. I suggest
> to introduce an empty interface named 'javax.ws.rs.RootResource' or
> alike. This interface would allow an OSGi bundle to expose its resources
> using the OSGi service registry using interface that is part of the
> official API.
>
I don't think an OSGi bundled JAX-RS application *needs* to export any
classes. I also don't think an OSGI service registry is appropriate for
JAX-RS components.
Instead, exposing only javax.ws.rs.core.Application classes would be a
better approach. As it is the JAX-RS implementation still needs to set
classloader boundaries with every incoming invocation, as AFAIK, this is
not something OSGi handles.
> A global class path scanning in OSGi is possible, but accessing
> instances of classes in bundles that do not explicitly expose them as a
> service would break the managed life cycle of bundle components.
>
Yeah, i haven't been very impressed with OSGi beyond its fine-grain
classloading.
> I'm sure that JAX-RS and OSGi is a powerful combination with an existing
> market.
>
IMO, OSGi is overhyped as I think it should be marketed more as a
framework developer consumable API rather than an application developer
consumable API.
> A second one is not really a barrier but a security issue concerning the
> static 'RuntimeDelegate.setInstance(RuntimeDelegate)' method. I
> recommend checking for an appropriate permission. This would allow to
> limit the invocation of that method to approved code only.
>
I think this is a good idea.
Bill