\chapter{Providers}
\label{providers}

The \jaxrs\ runtime is extended using application-supplied provider classes. A provider is annotated with \Provider\ and implements one or more interfaces defined by \jaxrs.

\section{Lifecycle and Environment}

By default a single instance of each provider class is instantiated for each \jaxrs\ application. First the constructor (see section \ref{provider_class_constructor}) is called, then any requested dependencies are injected (see chapter \ref{context}), then the appropriate provider methods may be called multiple times (simultaneously), and finally the object is made available for garbage collection.

An implementation MAY offer other provider lifecycles, mechanisms for specifying these are outside the scope of this specification. E.g. an implementation based on an inversion-of-control framework may support all of the lifecycle options provided by that framework.

\section{Constructors}
\label{provider_class_constructor}

Provider classes are instantiated by the \jaxrs\ runtime and MUST have a public constructor for which the \jaxrs\ runtime can provide all parameter values. Note that a zero argument constructor is permissible under this rule.

A public constructor MAY include parameters annotated with \Context - chapter \ref{context} defines the parameter types permitted for this annotation. Since providers may be created outside the scope of a particular request, only deployment-specific properties may be available from injected interfaces at construction time - request-specific properties are available when a provider method is called. If more than one public constructor can be used then an implementation MUST use the one with the most parameters. Choosing amongst constructors with the same number of parameters is implementation specific.

\section{Entity Providers}
\label{entity_providers}

Entity providers supply mapping services between representations and their associated Java types. Entity providers come in two flavors: \MsgRead\ and \MsgWrite\ described below.

\subsection{Message Body Reader}
\label{message_body_reader}

The \MsgRead\ interface defines the contract between the \jaxrs\ runtime and components that provide mapping services from representations to a corresponding Java type. A class wishing to provide such a service implements the \MsgRead\ interface and is annotated with \Provider.

The following describes the logical\footnote{Implementations are free to optimize their processing provided the results are equivalent to those that would be obtained if these steps are followed.} steps taken by a \jaxrs\ implementation when mapping a request entity body to a Java method parameter:

\begin{enumerate}
\item Identify the Java type of the parameter whose value will be mapped from the entity body. Section \ref{mapping_requests_to_java_methods} describes how the Java method is chosen.
\item Select the set of \MsgRead\ classes that support the media type of the request, see section \ref{declaring_provider_capabilities}.
\item\label{findreader} Iterate through the selected \MsgRead\ classes and, utilizing the \code{isReadable} method of each, choose a \MsgRead\ provider that supports the desired Java type.
\item If step \ref{findreader} locates a suitable \MsgRead\ then use its \code{readFrom} method to map the entity body to the desired Java type.
\item If step \ref{findreader} fails to locate a suitable \MsgRead\ then generate an unsupported media type response (HTTP 415 status).
\end{enumerate}

\subsection{Message Body Writer}
\label{message_body_writer}

The \MsgWrite\ interface defines the contract between the \jaxrs\ runtime and components that provide mapping services from a Java type to a representation. A class wishing to provide such a service implements the \MsgWrite\ interface and is annotated with \Provider.

The following describes the logical steps taken by a \jaxrs\ implementation when mapping a return value to a response entity body:

\begin{enumerate}
\item Obtain the object that will be mapped to the response entity body. For a return type of \Response\ or subclasses the object is the value of the \code{entity} property, for other return types it is the returned object.
\item Obtain the effective value of \ProduceMime\ (see section \ref{declaring_method_capabilities}) and intersect that with the requested response formats to obtain set of permissible media types for the response entity body. Note that section \ref{mapping_requests_to_java_methods} ensures that this set will not be empty.
\item Select the set of \MsgWrite\ providers that support (see section \ref{declaring_provider_capabilities}) one or more of the permissible media types for the response entity body.
\item Sort the selected \MsgWrite\ providers as described in section \ref{declaring_provider_capabilities}.
\item\label{findwriter} Iterate through the sorted \MsgWrite\ providers and, utilizing the \code{isWriteable} method of each, choose an \MsgWrite\ that supports the object that will be mapped to the entity body.
\item If step \ref{findwriter} locates a suitable \MsgWrite\ then use its \code{writeTo} method to map the object to the entity body.
\item If step \ref{findwriter} fails to locate a suitable \MsgWrite\ then generate a not acceptable response (HTTP 406 status).
\end{enumerate}

\subsection{Declaring Media Type Capabilities}
\label{declaring_provider_capabilities}

Message body readers and writers MAY restrict the media types they support using the \ConsumeMime\ and \ProduceMime\ annotations respectively. The absence of these annotations is equivalent to their inclusion with media type (\lq\lq*/*\rq\rq), i.e. absence implies that any media type is supported. An implementation MUST NOT use an entity provider for a media type that is not supported by that provider.

When choosing an entity provider an implementation sorts the available providers according to the media types they declare support for. Sorting of media types follows the general rule: x/y $<$ x/* $<$ */*, i.e. a provider that explicitly lists a media types is sorted before a provider that lists */*. Quality parameter values are also used such that x/y;q=1.0 $<$ x/y;q=0.7.

\subsection{Standard Entity Providers}
\label{standard_entity_providers}

An implementation MUST include pre-packaged \MsgRead\ and \MsgWrite\ implementations for the following Java and media type combinations:

\begin{description}
\item[\code{byte[]}] All media types (\code{*/*}).
\item[\code{java.lang.String}] All text media types (\code{text/*}).
\item[\code{java.io.InputStream}] All media types (\code{*/*}).
\item[\code{java.io.Reader}] All media types (\code{*/*}).
\item[\code{java.io.File}] All media types (\code{*/*}).
\item[\code{javax.activation.DataSource}] All media types (\code{*/*}).
\item[\code{javax.xml.transform.Source}] XML types (\code{text/xml}, \code{application\-/\-xml} and \code{application\-/\-*+xml}).
\item[\code{javax.xml.bind.JAXBElement} and application-supplied JAXB classes] XML media types (\code{text\-/\-xml}, \code{application/xml} and \code{application/*+xml}).
\item[\code{MultivaluedMap<String,String>}] Form content (\code{application/x-www-form-urlencoded}).
\item[\code{StreamingOutput}] All media types (\code{*/*}), \MsgWrite\ only.
\end{description}

When writing responses, implementations SHOULD respect application-supplied character set metadata and SHOULD use UTF-8 if a character set is not specified by the application or if the application specifies a character set that is unsupported.

An implementation MUST support application-provided entity providers and MUST use those in preference to its own pre-packaged providers when either could handle the same request.

\subsection{Transfer Encoding}

Transfer encoding for inbound data is handled by a component of the container or the \jaxrs\ runtime. \MsgRead\ providers always operate on the decoded HTTP entity body rather than directly on the HTTP message body.

\begin{ednote}Should JAX-RS require support for specific transfer encodings ?\end{ednote}

A JAX-RS runtime or container MAY transfer encode outbound data or this MAY be done by application code.

\subsection{Content Encoding}

Content encoding is the responsibility of the application. Application-supplied entity providers MAY perform such encoding and manipulate the HTTP headers accordingly.

\section{Context Providers}
\label{contextprovider}

Context providers supply context to resource classes and other providers. A context provider class implements the \code{ContextResolver<T>} interface and is annotated with \Provider. E.g. an application wishing to provide a customized \code{JAXBContext} to the default JAXB entity providers would supply a class implementing \code{ContextResolver<JAXBContext>}.

Context providers MAY return \code{null} from the \code{getContext} method if they do not wish to provide their context for a particular Java type. E.g. a JAXB context provider may wish to only provide the context for certain JAXB classes. Context providers MAY also manage multiple contexts of the same type keyed to different Java types.

Section \ref{contextresolver} describes how to access a context provider from a resource class or provider.