On Mar 21, 2012, at 8:08 PM, Bill Burke wrote:
>
>
> On 3/21/12 3:01 PM, Marek Potociar wrote:
>>
>> On Mar 19, 2012, at 3:01 PM, Bill Burke wrote:
>>
>>>
>>>
>>> On 3/15/12 4:15 PM, Santiago Pericas-Geertsen wrote:
>>>>
>>>> On Mar 15, 2012, at 4:00 PM, Bill Burke wrote:
>>>>
>>>>>
>>>>>
>>>>> On 3/15/12 3:54 PM, Santiago Pericas-Geertsen wrote:
>>>>>>
>>>>>> On Mar 15, 2012, at 3:31 PM, Bill Burke wrote:
>>>>>>
>>>>>>> I would say do nothing because it would break existing 1.1 applications when deployed.
>>>>>>
>>>>>> How so? Before you had to always specify the mapping, and that will continue to take precedence. Can you elaborate?
>>>>>>
>>>>> We assumed everything could be scanned, you could have an empty web.xml file, and no Application class. This was an incorrect assumption? I know a lot of people use us in this manner. Maybe I just interpreted the 1.1 spec wrong?
>>>>
>>>> Class scanning and servlet mapping are orthogonal. The only way you can get the servlet mapping in 1.1 is from (i) a web.xml or (ii) the @ApplicationPath annotation on an Application subclass AFAICT, with (i) overriding (ii) if both are present. For the other cases, 1.1 states that "the application MUST be packaged with a web.xml that specifies a servlet mapping for the added servlet".
>>>>
>>>> Perhaps you're already using a default in Resteasy?
>>>>
>>>
>>> Well, then the spec should allow the case for *no* Application class and no web.xml listing. The default mapping should be "/*" and should work with static content too. This way its very simple for users and no thought has to be put into anything.
>>>
>>
>> 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.
Didn't I just tell you? Other JavaEE specs (afaik JSF uses "/faces") (and possibly other EE technologies) define their default mappings. Users using combination of these technologies in a single application should not be required to resolve any conflicts caused by the default mappings. Reserving conservatively a single named subtree of the application URI space is a better option ("live and let live") with a positive impact on the end-user convenience.
> 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.
I agree.
Marek
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com