Updates to spec to match current draft changelog
svn path=/trunk/; revision=578
diff --git a/spec/chapters/annotations.tex b/spec/chapters/annotations.tex
index 51f91e1..9a47e75 100644
--- a/spec/chapters/annotations.tex
+++ b/spec/chapters/annotations.tex
@@ -18,6 +18,8 @@
\hline
\code{HEAD} & \raggedright Method & \raggedright Specifies that the annotated method handles HTTP HEAD requests. Note that HEAD may be automatically handled, see section \ref{head_and_options}. \tabularnewline
\hline
+\code{ApplicationPath} & \raggedright Type & \raggedright Specifies the resource-wide application path that forms the base URI of all root resource classes. \tabularnewline
+\hline
\code{Path} & \raggedright Type or method & \raggedright Specifies a relative path for a resource. When used on a class this annotation identifies that class as a root resource. When used on a method this annotation identifies a sub-resource method or locator. \tabularnewline
\hline
\code{PathParam} & \raggedright Parameter, field or method & \raggedright Specifies that the value of a method parameter, class field, or bean property is to be extracted from the request URI path. The value of the annotation identifies the name of a URI template parameter.\tabularnewline
diff --git a/spec/chapters/applications.tex b/spec/chapters/applications.tex
index 769b221..4a1c290 100644
--- a/spec/chapters/applications.tex
+++ b/spec/chapters/applications.tex
@@ -29,11 +29,23 @@
\subsection{Servlet}
\label{servlet}
-A \jaxrs\ application is packaged as a Web application in a \code{.war} Þle. The \code{Application} subclass (see section \ref{config}), resource classes, and providers are packaged in \code{WEB-INF/classes}, required libraries are packaged in \code{WEB-INF/lib}. Included libraries MAY also contain resource classes and providers as desired. See the Servlet speciÞcation for full details on packaging of web applications.
+A \jaxrs\ application is packaged as a Web application in a \code{.war} file. The application classes are packaged in \code{WEB-INF/classes} or \code{WEB-INF/lib} and required libraries are packaged in \code{WEB-INF/lib}. See the Servlet specification for full details on packaging of web applications.
-When using a Servlet 3 container, the \code{Application} subclass is optional. By default, all root resource classes and providers packaged in the web application MUST be included in the published JAX-RS application. An \code{Application} subclass MAY be included in a \code{.war} file to override the default behavior. If both \code{getClasses} and \code{getSingletons} return an empty list then the default set of classes MUST be used. It is RECOMMENDED that implementations support the Servlet 3 framework pluggability mechanism to enable portability between containers and to avail themselves of container-supplied class scanning facilities.
+It is RECOMMENDED that implementations support the Servlet 3 framework pluggability mechanism to enable portability between containers and to avail themselves of container-supplied class scanning facilities. When using the pluggability mechanism the following conditions MUST be met:
-When using a non-\jaxrs\ aware servlet container, the \code{servlet-class} or \code{filter-class} element of the web.xml descriptor SHOULD name the JAX-RS implementation-supplied \code{Servlet} or \code{Filter} class respectively. The application-supplied subclass of \code{Application} is identiÞed using an \code{init-param} with a \code{param-name} of \code{javax\-.ws\-.rs\-.Application}.
+\begin{itemize}
+\item If no \code{Application} subclass is present the added servlet MUST be named:
+\begin{quote}\code{javax.\-ws.\-rs.\-core.\-Application}\end{quote} and all root resource classes and providers packaged in the web application MUST be included in the published \jaxrs\ application. The application MUST be packaged with a \code{web.xml} that specifies a servlet mapping for the added servlet.
+
+\item If an \code{Application} subclass is present and there is already a servlet defined that has a servlet initialization parameter named: \begin{quote}\code{javax.ws.rs.Application}\end{quote} whose value is the fully qualified name of the \code{Application} subclass then no new servlet should be added by the \jaxrs\ implementation's \code{ContainerInitializer} since the application is already being handled by an existing servlet.
+
+\item If an \code{Application} subclass is present that is not being handled by an existing servlet then the servlet added by the \code{ContainerInitializer} MUST be named with the fully qualified name of the \code{Application} subclass. If the \code{Application} subclass is annotated with \code{@ApplicationPath} and no servlet-mapping exists for the added servlet then a new servlet mapping is added with the value of the \code{@ApplicationPath} annotation with "/*" appended otherwise the existing mapping is used. If the \code{Application }subclass is not annotated with \code{@ApplicationPath}\ then the application MUST be packaged with a \code{web.xml} that specifies a servlet mapping for the added servlet. It is an error for more than one application to be deployed at the same effective servlet mapping
+\end{itemize}
+
+In either of the latter two cases, if both \code{Application.getClasses} and \code{Application.getSingletons} return an empty list then all root resource classes and providers packaged in the web application MUST be included in the published \jaxrs\ application. If either \code{getClasses} or \code{getSingletons} return a non-empty list then only those classes or singletons returned MUST be included in the published \jaxrs\ application.
+
+If not using the Servlet 3 framework pluggability mechanism (e.g. in a pre-Servet 3.0 container), the \code{servlet-class} or \code{filter-class} element of the \code{web.xml} descriptor SHOULD name the \jaxrs\ implementation-supplied servlet or filter class respectively. The \code{Application} subclass SHOULD be identified using an \code{init-param} with a \code{param-name} of \code{javax.\-ws.\-rs.\-Application}.
+
\subsection{Other Container}
diff --git a/spec/chapters/context.tex b/spec/chapters/context.tex
index e5afeb0..3a01ae6 100644
--- a/spec/chapters/context.tex
+++ b/spec/chapters/context.tex
@@ -10,7 +10,11 @@
\section{Context Types}
\label{contexttypes}
-This section describes the types of context available to resource classes and providers.
+This section describes the types of context available to resource classes, providers and \code{Application} subclasses.
+
+\subsection{Application}
+
+The instance of the application-supplied \code{Application} subclass can be injected into a class field or method parameter using the \Context\ annotation. Access to the \code{Application} subclass instance allows configuration information to be centralized in that class. Note that this cannot be injected into the \code{Application} subclass itself since this would create a circular dependency.
\subsection{URIs and URI Templates}
diff --git a/spec/chapters/environment.tex b/spec/chapters/environment.tex
index f15db3e..2705f10 100644
--- a/spec/chapters/environment.tex
+++ b/spec/chapters/environment.tex
@@ -17,13 +17,13 @@
\section{Java EE Container}
\label{javaee}
-This section describes the additional features available to an application hosted in a Java EE 6 container that supports \jaxrs.
+This section describes the additional requirements that apply to a \jaxrs\ implementation when combined in a product that supports these other Java specifications:
-An implementation MUST support applications packaged as described in section \ref{servlet}. An implementation MUST support use of session beans as root resource classes and stateless session and singleton beans as providers in a Web application. \jaxrs\ annotations MAY be applied to a bean's local interface or directly to a no-interface bean.
-
-\begin{note}The new \code{java:module} JNDI context enables easy lookup of a bean instance given a bean local interface or class name.\end{note}
-
-In a container that also includes support for JSR-299 (Contexts and Dependency Injection for Java), an implementation MUST support use of JSR-299 beans as root resource classes, providers and as \code{Application} subclasses in a Web application. \code{Provider} and \code{Application} classes MUST use application scope. \jaxrs\ annotations MAY be directly applied to JSR-299 beans and the \jaxrs\ implementation MUST the appropriate APIs to obtain bean instances that use JSR-299 facilities.
+\begin{itemize}
+\item In a product that also supports the Servlet specification, implementations MUST support \jaxrs\ applications that are packaged as a web application, see section \ref{servlet}.
+\item In a product that also supports Managed Beans, implementations MUST support use of Managed Beans as root resource classes, providers and \code{Application} subclasses. All such classes may make use of any container-supplied facilities including dependency injection and interceptors. Providers and \code{Application} subclasses MUST be singletons or use application scope.
+\item In a product that also supports EJB, an implementation MUST support use of stateless and singleton session beans as root resource classes, providers and \code{Application} subclasses in a Web application. \jaxrs\ annotations MAY be applied to a beanÕs local interface or directly to a no-interface bean. If an \code{Exception\-Mapper} for a \code{EJBException} or subclass is not included with an application then exceptions thrown by an EJB resource class or provider method MUST be treated as EJB application exceptions: the embedded cause of the \code{EJBException} MUST be unwrapped and processed as described in section \ref{method_exc}.
+\end{itemize}
\section{Other}
diff --git a/spec/chapters/resources.tex b/spec/chapters/resources.tex
index 1aa88aa..e25d2db 100644
--- a/spec/chapters/resources.tex
+++ b/spec/chapters/resources.tex
@@ -167,7 +167,7 @@
\section{URI Templates}
\label{uritemplates}
-A root resource class is anchored in URI space using the \Path\ annotation. The value of the annotation is a relative URI path template whose base URI is provided by the deployment context.
+A root resource class is anchored in URI space using the \Path\ annotation. The value of the annotation is a relative URI path template whose base URI is provided by the combination of the deployment context and the application path (see the \code{@Application\-Path} annotation).
A URI path template is a string with zero or more embedded parameters that, when values are substituted for all the parameters, is a valid URI\cite{uri} path. The Javadoc for the \Path\ annotation describes their syntax. E.g.:
