dev@jsr311.java.net

Re: JSR311: Support for OSGi Service Platform

From: Tobias Hofer <tobias.hofer_at_basis06.com>
Date: Tue, 12 Aug 2008 20:24:53 +0200

On Tue, 2008-08-12 at 10:37 -0400, Marc Hadley wrote:
> On Aug 12, 2008, at 9:18 AM, 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.
> >
> > 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.
> >
> > 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.
> >
> I'm a complete OSGi novice but it seems like a big step backwards to
> require root resource classes to implement an empty marker interface.
Yes, i agree, an empty marker interface is a step backward.

It is possible to directly register a service using the Object class as
service interface, but that service type is not really meaningful.

>
> How are other annotation driven technologies (e.g. JAX-WS) supported
> in OSGi ?
In OSGi there's a class loading concept that encapsulates bundle
resources from each other. So bundles can be loaded and unloaded on
runtime. A class is not a static resource that exists all the time.
Therefore do concepts, that rely on that fact, not work as easy in such
environments.

>
> Marc.
>
> > 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.
> >
> > Thanks in advance for considering this issues.
> >
> > Tobias Hofer
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> > For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> >
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.