> so my question(s) are:
>
> -Does glassfish v3 support what is mentioned before???
Yes.
> - What servlet does the spec. takes about by saying :
> " If an Application subclass is present that is not being handled by
> an existing servlet then the servlet added by the
> ContainerInitializerMUST be named with the fully qualified name of
> the Application subclass."
The servlet spec does not need to say anything because Jersey, which
implements JAX-RS 1.1, uses a plug-in feature of Servlet 3.0,
specifically a ServletContainerInitializer [1] and see [2] for
Jersey's implementation.
See attached for some simple maven-based projects that exercise this
feature.
Paul.
[1]
http://java.sun.com/javaee/6/docs/api/javax/servlet/ServletContainerInitializer.html
[2]
http://fisheye4.atlassian.com/browse/jersey/trunk/jersey/jersey-server/src/main/java/com/sun/jersey/server/impl/container/servlet/JerseyServletContainerInitializer.java?r=HEAD
> [Message sent by forum member 'mohammed_qaimari' ]
On Dec 13, 2009, at 10:54 PM, glassfish_at_javadesktop.org wrote:
> The following is a part of JAX-RS 1.1 specification:
>
> 2.3.2 Servlet
> A JAX-RS application is packaged as a Web application in a .war
> file. The application classes are packaged in WEB-INF/classes or WEB-
> INF/lib and required libraries are packaged in WEB-INF/lib. See the
> Servlet specification for full details on packaging of web
> applications.
> 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:
> • If no Application subclass is present the added servlet MUST be
> named:
> javax.ws.rs.core.Application and all root resource classes and
> providers packaged in the web application MUST be included in the
> published JAX-RS application. The application MUST be packaged with
> a web.xml that specifies a servlet mapping for the added servlet.
> • If an Application subclass is present and there is already a
> servlet defined that has a servlet initialization parameter named:
> javax.ws.rs.Application
> whose value is the fully qualified name of the Application subclass
> then no new servlet should be
> added by the JAX-RS implementation’s ContainerInitializer since the
> application is already being handled by an existing servlet.
> • If an Application subclass is present that is not being handled by
> an existing servlet then the servlet added by the
> ContainerInitializerMUST be named with the fully qualified name of
> the Application subclass. If the Application subclass is annotated
> with @ApplicationPath and no servlet-mapping exists for the added
> servlet then a new servlet mapping is added with the value of
> the @ApplicationPath annotation with ”/*” appended otherwise the
> existing mapping is used. If the Application subclass is not
> annotated with @ApplicationPath then the application MUST be
> packaged with a 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
> In either of the latter two cases, if both Application.getClasses
> and Application.getSingletons
> return an empty list then all root resource classes and providers
> packaged in the web application MUST
> be included in the published JAX-RS application. If either
> getClasses or getSingletons return a
> non-empty list then only those classes or singletons returned MUST
> be included in the published JAX-RS
> application.
> If not using the Servlet 3 framework pluggability mechanism (e.g. in
> a pre-Servet 3.0 container), the
> servlet-class or filter-class element of the web.xml descriptor
> SHOULD name the JAX-RS
> implementation-supplied servlet or filter class respectively. The
> Application subclass SHOULD be identified
> using an init-param with a param-name of javax.ws.rs.Application.
>
>
>
> http://forums.java.net/jive/thread.jspa?messageID=376294
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>