[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Default Servlet Mapping?
- From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen@...>
- To: jsr339-experts@...
- Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Default Servlet Mapping?
- 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
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
Does this make sense?