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> 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.
Even with the proposed @DefaultMethod, you'd have add a @DefaultMethod
method to every single resource class where you wanted to handle default
beahvior. If you had backtracking, you could have one resource class
handle default behavior. Which is easier to use?
I'm not being difficult for something trivial. Creating default
behavior should be easy, and its not. I've had users complain about
this, not many, but some, specifically because their old code which
relied on backtracking didn't work when they upgraded. I've spelled
this out in a detailed blog over 2 years ago, and even wrote this in my
book about how things you'd expect to work, don't, for situations that
are *NOT* uncommon. Default method behavior being one of them...
http://bill.burkecentral.com/2013/05/29/the-poor-jax-rs-request-dispatching-algorithm/
Read the comment by Einar. He wanted to create default behavior and
encapsulate it in a class. Couldn't do it with strict matching behavior.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com