[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Default Servlet Mapping?

From: Santiago Pericas-Geertsen <>
Date: Fri, 23 Mar 2012 10:24:09 -0400

On Mar 22, 2012, at 10:41 AM, Bill Burke wrote:

>>>> I think so far we can all agree, that a default mapping is good. I
>>>> want to however point out that suggested "/*" as a default mapping is
>>>> too aggressive in connection with any other technology that uses some
>>>> default mapping as well (e.g. JSF). For that reason, I suggest to
>>>> choose a named default mapping directly under the root path e.g. the
>>>> "/webapi/*" as proposed earlier.
>>> Please tell me why "/*" is too aggressive? its easily handled if your
>>> implementation is Filter based.
>>> But, this is orthogonal to the issue of requiring a web.xml or
>>> Application class. I do not think either of these artifacts should be
>>> required to deploy a JAX-RS service.
>> Without Application, what would be the most portable way to deploy a
>> simple JAX-RS service across multiple JAX-RS stacks ? Sorry may be this
>> question is also orthogonal :-),
> Not sure I understand you. just put a resource class in /WEB-INF/classes and have the scanner discover it. Seems pretty straightforward to me. YOu want a full Java EE container to have value-add. One of the value adds is scanning.

 It depends exactly what's covered by "portability". Yes, the resources can be discovered via class scanning, which is great; however, the _location_ of those resources depends on the servlet mapping which is coming either from the web.xml or @ApplicationPath according to JAX-RS 1.X.

 The point of this thread was to define a default servlet mapping so the location (at least after the application context root) is also portable in the absence of a web.xml and @ApplicationPath. I have a sense that most JAX-RS app developers want to neither write a web.xml nor provide an application subclass with a @ApplicationPath. Hence, the usefulness of a default mapping.

 Does this make sense?

-- Santiago