Hi Bill,
@DefaultMethod is not an option for dealing with failed matches.
It is just a verb method wildcard. Nothing would change in the algorithm
apart from the few clarifications on the filtering.
IMHO it just adds much more confusion to the discussion, talking about
all the match issues in context of this discussion. I'm fine with you
exploring the options to improve but please do use another thread for it :-)
Here is the example from a test I did to our code:
@Path("service")
public class DefaultMethodResource {
@Path("all")
@DefaultMethod
public Response all() {
return null;
}
@Path("all")
@GET
public Response getAll() {
return null;
}
@GET
public Response get() {
return null;
}
}
PUT /service/all -> all()
GET /service/all -> getAll()
GET /service -> get()
Nothing new. Just an optional method wild-card support.
I'm fine to be honest with it either to be accepted or not, I just need
this extension fr my own work either way, so I'm proceeding :-)
Sergey
On 23/01/15 15:00, Santiago Pericas-Geertsen wrote:
>
>> On Jan 23, 2015, at 9:26 AM, Bill Burke <bburke_at_redhat.com
>> <mailto:bburke_at_redhat.com>> wrote:
>>
>>
>>
>> On 1/23/2015 8:13 AM, Santiago Pericas-Geertsen wrote:
>>>
>>>> On Jan 22, 2015, at 5:27 PM, Bill Burke <bburke_at_redhat.com
>>>> <mailto:bburke_at_redhat.com>> wrote:
>>>>
>>>> Markus, maybe we're both confused on what exactly is being suggested
>>>> here. Thought I already stated my counterproposal:
>>>>
>>>> Fix the matching algorithm to support backtracking. Then, for
>>>> example, if you want to provide default OPTIONS support you just
>>>> define a resource class, subrsource class, and/or resource method to
>>>> do that. Its what we supported for years and years until the TCK got
>>>> strict. If you want to avoid typos for wildcards, add a constant to
>>>> @Path
>>>>
>>>> static final string WILDCARD = "{wildcard:.*}”;
>>>
>>> I believe what Sergey is proposing is to add a default method to a
>>> path that already matches, which is slightly different (and much
>>> simpler) than matching on all paths and using backtracking to get
>>> there. The application code will look very different.
>>>
>>> As for backtracking, I believe we already had this discussion; the
>>> formalization of a backtracking algorithm has a lot of little details
>>> that need to be worked out to ensure compatibility, most notably, the
>>> ordering in which the different alternatives are tried when backtracking.
>>>
>>> We have had the users' alias open for years, and I don’t recall any
>>> requests about this. So, although I can see some users benefiting
>>> from backtracking, I’m not convinced this represents a significant
>>> portion of the developer community as you seem to imply.
>>>
>>
>> You can't say that you're not convinced backtracking effects a
>> significant portion of the dev community, then support adding
>> something like @DefaultMethod which also doesn't effect a significant
>> portion of the dev community.
>
> I’m on the fence with @DefaultMethod, but it’s worth exploring. And,
> yes, I can support one and not the other because the cost-benefit of
> @DefaultMethod seems far better.
>
>> Even with the proposed @DefaultMethod, you'd have add a @DefaultMethod
>> method to every single resource class where you wanted to handle
>> default beahvior.
> No, as I see it this use case is the exception, not the rule. If most
> users would need to add @DefaultMethod on most resource classes,
> something different would be need it.
>
> — Santiago
>