Re: JSR311: Support for OSGi Service Platform

From: Bill Burke <>
Date: Tue, 12 Aug 2008 16:30:11 -0400

I hope you don't mind arguing about this... I'm not trying to be a
jerk, but rather to make sure that my assumptions are correct.

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.
> 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.

mature that it solves life cycle for its own component model.
Unfortunately, there's tons of popular non-OSGi component models.

> I'm not sure what you declare as a modern user-friendly component
> model...

Seam, Web Beans, EJB 3, Spring, Guice, GBeans (Geronimo), JBoss Beans
(AS 5), and even JMX Service Beans (JBoss AS 4 and earlier). All could
have cross bundle dependencies.

>>> One of them is the lack of a root resource service interface. I suggest
>>> to introduce an empty interface named '' 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.

The problem is, again, there are different popular component
architectures out there. The main ones being Spring, EJB 3, Seam, and
maybe even Guice.

Most users would be writing a component that is registered with the
JAX-RS runtime. In other words, you would be using Spring, EJB 3, Seam,
Web Beans, or Guice to define your JAX-RS resources. You wouldn't be
using the default JAX-RS component model.

>> Instead, exposing only 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, 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 is not very user-friendly to
> implement. That requires every bundle to implement an additional class.

Application is as user friendly you are going to get considering the
number of popular component models out there.

> 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.

User friendly for OSGi, not user-friendly in general. I know one of the
things we're solving in JBoss's new kernel is the ability to
automatically manage dependencies and lifecycle that could be
cross-bundle, cross-component, and even cross-component model. And to
do it transparently without additional metadata. I know we couldn't do
this with the current state of OSGi which is why we're trying to work
with the specification.

> 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.

I disagree. IMO, we need a common kernel, but OSGi isn't complete
enough to get to the level of user-friendliness we should aspire to.

Bill Burke
JBoss, a division of Red Hat