RFC-217 support for Feature, DynamicFeature, ContextResolver and other providers

[bjhargrave]

Original bug ID: BZ#202
From: Karel Haeck <[email protected]>
Reported version: unspecified

[bjhargrave]

Comment author: Karel Haeck <[email protected]>

the current draft only supports providers of Filters, Interceptors, BodyReaders and BodyWriters. The jax-rs spec also defines Feature, DynamicFeature, ContextResolver,
ExceptionMapper and ParamConverterProvider.
It would be much simpler to have a single property osgi.jaxrs.provider.base, regardless of provider type,
as all providers share the characteristic that the base url matches all subpaths.

Note also that standard jax-rs javax.ws.core.Feature functionality is quite similar to the newly proposed rfc specific JaxRSContext

[bjhargrave]

Comment author: @timothyjward

(In reply to Karel Haeck from comment BZ#0)

the current draft only supports providers of Filters, Interceptors,
BodyReaders and BodyWriters. The jax-rs spec also defines Feature,
DynamicFeature, ContextResolver,
ExceptionMapper and ParamConverterProvider.
It would be much simpler to have a single property osgi.jaxrs.provider.base,
regardless of provider type,
as all providers share the characteristic that the base url matches all
subpaths.

We agreed something very similar to this at the Expert Group Face to Face meeting last week. The original intent was to map closely to the Http Service Whiteboard, which uses different property names, but there are a sufficiently large number of different types with similar semantics here that a common property does seem to be a better choice.

Note also that standard jax-rs javax.ws.core.Feature functionality is quite
similar to the newly proposed rfc specific JaxRSContext

We will look again at the additional types, particularly the use of Feature, which may be able to replace JaxRSContext, but the intent of the spec is not necessarily to provide a 100% mapping of the JAX-RS API to a whiteboard model, at least for the first version of the whiteboard specification. Applications which make heavy use of the JAX-RS specification can always fall back to registering an Application with the whiteboard.

The ContextResolver is a good example of a service that probably does not need to be part of the whiteboard - whiteboard resources will typically be singletons, and will use Declarative Services or some other injection technology to get access to OSGi service dependencies. The use of @ Context for custom injection is therefore likely to be limited to method injection for built-in JAX-RS types, and using a ContextResolver therefore broadly unnecessary. DynamicFeatures appear to be similarly unnecessary, they provide exactly the same behaviour as registering several Filters, or registering a Feature.

In general we want to ensure that the whiteboard is useful, but also to prevent it from becoming overly complex.

If you have a specific use case that you are concerned about then it would be valuable to know what it is.

[bjhargrave]

Comment author: Karel Haeck <[email protected]>

My primary use case for a ContextResolver is not for direct use in a Resource, but for customization of other feature's. e.g. In Jersey I may add a JacksonFeature to use the Jackson library for JSON (de)serializing, and then register a ContextResolver to control how objects are (de)serialized to/from JSON.

Motivation for DynamicFeature is to reuse existing components. e.g. Jersey provides a
RolesAllowedDynamicFeature, that bridges a resource method's @ RolesAllowed annotation with SecurityContext.isUserInRole(String). While there are other ways to implement this, it just happens to be implemented as a DynamicFeature.

I agree that a 100% mapping of JAX-RS features to the whiteboard should not be a goal, but by not caring about the provider type, the whiteboard automatically supports all of the provider types.