Skip to main content
Last updated August 01, 2012 14:00, by m_potociar

Common JAX-RS Configuration

This proposal attempts to evolve the existing client-side Feature into a common solution factoring in also the existing proposal around DynamicBinder API. In summary, it is proposed to:

1. Update the register(...) methods in the client-side Configuration by adding new vararg contracts parameters to address the issue with a single provider instance implementing potentially multiple contracts:

public interface Configuration {
    <T> Configuration register(Class<T> provider, Class<? super T>... contracts);
    <T> Configuration register(T provider, Class<? super T>... contracts);
If the contracts are not specified, the methods would work as usual - register the provider class/instance as a provider of all the recognised contracts implemented by the provider class/instance. However in case one or more contracts would be specified, the methods would only register the provider class/instance for the explicitly specified contract types.

2. Introduce a new common Configurable interface (originally derived from client-side Configuration):

public interface Configurable {
    Map<String, Object> getProperties();
    Object getProperty(String name);
    Configurable setProperties(Map<String, ? extends Object> properties);
    Configurable setProperty(String name, Object value);

    Collection<Feature> getConfiguredFeatures();
    Set<Class<?>> getProviderClasses();
    Set<Object> getProviderInstances();

    Configurable register(Class<?> provider);
    Configurable register(Object provider);
    <T> Configurable register(Class<T> provider, Class<? super T>... contracts);
    <T> Configurable register(T provider, Class<? super T>... contracts);
Note that client-side Configuration would not implement this interface - that decision would be left upon implementation providers.

3. Update the Feature API and move it to common package:

public interface Feature {
    public void configure(Configurable configurable);

4. Update API documentation to mention that container as well as common Feature implementation classes/instances can be returned from either getClasses() or getSingletons(). JAX-RS implementations would be then required to "resolve" the returned Feature providers as part of the application initialization.

5. Replace the DynamicBinder with a (container-specific) DynamicFeature API:

public interface DynamicFeature {
    public void configure(ResourceInfo resourceInfo, Configurable configurable);
Here the configurable would be specific to each particular resource-info instance, i.e. it would be scoped per (sub)resource method. We would also place here restrictions (via DynamicFeature javadoc) on what types of contracts must be supported by JAX-RS implementations (container filters and interceptors are those that come to my mind at the moment) and then leave the doors open for any implementation-specific extensions to the rule.

Please Confirm