> > 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.
Most existing applications and libraries rely on a static and monolithic
deployment and therefore cause problems in a more dynamic environment.
So do most component framework behave. They ignore that a component can
have its own development and deployment life cycle.
The original focus of OSGi was on service gateways but the applicability
is much wider. IMHO the OSGi Framework is mature and very modern even if
it's origin can be dated back to 2k.
I'm not sure what you declare as a modern user-friendly component
model...
> > 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.
Exactly right. There's no need to export any classes. But the bundle
must provide information about the services it provides. That
information is used by the framework to wire bundles and their
components together.
> 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.
That's true, javax.ws.rs.core.Application allows to return instances and
not only classes as its predecessor did. It is very important to be able
to return instances in order let the framework handle the component's
life cycle.
But the javax.ws.rs.core.Application is not very user-friendly to
implement. That requires every bundle to implement an additional class.
I know, that my proposal of an empty interface is not the best solution
(redundancy, etc) but it would allow a more user-friendly way in
exposing a JAX-RS component than the Application class does.
I do understand your opposition against that additional interface. In
fact it is possible to use the java.lang.Object as service type, but
that's not really a service contract. I'll have to live with that.
> > 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 like the life cycle handling of components in OSGi.
> > 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.
I agree, OSGi is overhyped. But that does not derogate the specification
nor its usage. And yes, there is first the need of frameworks that will
work on OSGi, but I don't think that they need to encapsulate and hide
OSGi in order to get application developer ready.
> > 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
Best thanks for your feedback.
Tobias