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