Module jakarta.ws.rs
Package jakarta.ws.rs.core

Interface Configurable<C extends Configurable>

Type Parameters:
C - generic configurable Java type
All Known Subinterfaces:
Client, FeatureContext, WebTarget
All Known Implementing Classes:
ClientBuilder
public interface Configurable<C extends Configurable>
Represents a client or server-side configurable context in JAX-RS. A configurable context can be used to define the JAX-RS components as well as additional meta-data that should be used in the scope of the configured context. The modification of the context typically involves setting properties or registering custom JAX-RS components, such as providers and/or features. All modifications of a Configurable context are reflected in the associated Configuration state which is exposed via getConfiguration() method.

A configurable context can be either indirectly associated with a particular JAX-RS component (such as application or resource method configurable context passed to a Feature or DynamicFeature meta-providers) or can be directly represented by a concrete JAX-RS component implementing the Configurable interface (such as Client or WebTarget). As such, the exact scope of a configuration context is typically determined by a use case scenario in which the context is accessed.

Setting properties.

New properties can be set using the property(java.lang.String, java.lang.Object) method. Similarly, updating a value of an existing property can be achieved using the same method. Information about the configured set of properties is available via the underlying Configuration object. An existing property can be removed by assigning a null value to the property.

Registering JAX-RS components.

Registered custom JAX-RS component classes and instances are important part of the contextual configuration information as these are the main factors that determine the capabilities of a configured runtime. Implementations SHOULD warn about and ignore registrations that do not conform to the requirements of supported JAX-RS components in a given configurable context.

In most cases, when registering a JAX-RS component, the simplest form of methods (register(Class) or register(Object)) of the available registration API is sufficient.

For example: 

 config.register(HtmlDocumentReader.class);
 config.register(new HtmlDocumentWriter(writerConfig));

In some situations a JAX-RS component class or instance may implement multiple provider contracts recognized by a JAX-RS implementation (e.g. filter, interceptor or entity provider). By default, the JAX-RS implementation MUST register the new component class or instance as a provider for all the recognized provider contracts implemented by the component class.

For example: 

 @Priority(ENTITY_CODER)
 public class GzipInterceptor
         implements ReaderInterceptor, WriterInterceptor { ... }

 ...

 // register GzipInterceptor as a ReaderInterceptor
 // as well as a WriterInterceptor
 config.register(GzipInterceptor.class);

There are however situations when the default registration of a JAX-RS component to all the recognized provider contracts is not desirable. In such cases users may use other versions of the register(...) method to explicitly specify the collection of the provider contracts for which the JAX-RS component should be registered and/or the priority of each registered provider contract.

For example: 

 @Priority(USER)
 public class ClientLoggingFilter
         implements ClientRequestFilter, ClientResponseFilter { ... }

 @Priority(ENTITY_CODER)
 public class GzipInterceptor
         implements ReaderInterceptor, WriterInterceptor { ... }

 ...

 // register ClientLoggingFilter as a ClientResponseFilter only
 config.register(ClientLoggingFilter.class, ClientResponseFilter.class);

 // override the priority of registered GzipInterceptor
 // and both of it's provider contracts
 config.register(GzipInterceptor.class, 6500);

As a general rule, for each JAX-RS component class there can be at most one registration — class-based or instance-based — configured at any given moment. Implementations MUST reject any attempts to configure a new registration for a provider class that has been already registered in the given configurable context earlier. Implementations SHOULD also raise a warning to inform the user about the rejected component registration.

For example: 

 config.register(GzipInterceptor.class, WriterInterceptor.class);
 config.register(GzipInterceptor.class); // Rejected by runtime.
 config.register(new GzipInterceptor()); // Rejected by runtime.
 config.register(GzipInterceptor.class, 6500); // Rejected by runtime.

 config.register(new ClientLoggingFilter());
 config.register(ClientLoggingFilter.class); // rejected by runtime.
 config.register(ClientLoggingFilter.class,
         ClientResponseFilter.class); // Rejected by runtime.
Since:
2.0