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 {@code register(...)} method to explicitly specify the collection of the provider contractsfor which the JAX-RS component should be registered and/or the binding priority of each registered provider contract.
For example:
@BindingPriority(USER) public class ClientLoggingFilter implements ClientRequestFilter, ClientResponseFilter { ... } @BindingPriority(ENTITY_CODER) public class GzipInterceptor implements ReaderInterceptor, WriterInterceptor { ... } ... // register ClientLoggingFilter as a ClientResponseFilter only config.register(ClientLoggingFilter.class, ClientResponseFilter.class); // override the binding 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.@author Marek Potociar @since 2.0
Any class marked as Configurable may have a context including its sub-configuration passed to it, requesting it configure itself.
This interface can also be used for actors which load configuration information from non-XML formats, such as GIF images or binary lookup tables. The source argument of the configure() method simply points to such a file.
This interface is designed to be reversible, so that an object can also provide enough information to reconstruct its current configuration. This mechanism is used when writing MoML from instantiated objects, although it could also be used to write a description of the object in other forms. In order for this to work properly calling the configure method on any object of the same type, given the data returned by the getSource and getText methods should result in an object that resemble the first as closely as possible. @author Edward A. Lee, Steve Neuendorffer @version $Id: Configurable.java,v 1.22 2005/07/08 19:59:15 cxh Exp $ @since Ptolemy II 1.0 @Pt.ProposedRating Green (neuendor) @Pt.AcceptedRating Green (bart) @see ptolemy.actor.CompositeActor @see ptolemy.actor.AtomicActor
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |