> 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.
— Santiago
>
>
> As it is, support for backtracking should be added anyways as the current status quo is confusing to users.
>
> On 1/22/2015 1:18 PM, Markus KARG wrote:
>> Maybe it would be best if you provide a short counterproposal, how to extend the specification. Then we can discuss whether backtracking is the solution or the default annotation. :-)
>>
>> -----Original Message-----
>> From: Bill Burke [mailto:bburke_at_redhat.com]
>> Sent: Mittwoch, 21. Januar 2015 21:58
>> To: jsr370-experts_at_jax-rs-spec.java.net
>> Subject: Re: JAX-WS like Provider in JAX-RS
>>
>> Elaborate how @DefaultMethod is different than fixed backtracking. You can write the Backtracked method to be as specific (or as unspecific) as you want... With fixed backtracking you could have default methods wherever you wanted too and as many as you wanted. Complete flexibility...AND...As I said numerous times in 2013, users expect backtracking to work and are puzzled when it doesn't!
>>
>> -1 from me so far on @DefaultMethod. I don't see anything here that isn't more than a patch for a poor matching algorithm.
>>
>> On 1/21/2015 12:19 PM, Markus KARG wrote:
>>> I think there is a difference actually. Even with fixed backtracking, @DefaultMethod's semantics is to be a unique "catch any problem" disclaimer -- it catches even in case there are typos in the pattern, hence it can serve as a safety net in case "/{wildcard:.*}" is missing or wrongly typed, or in case there are two or more different patterns effectively matching on the same path but would route to different methods otherwise. Hence I see it as an additional option to fixing the algorithm.
>>>
>>> Regards
>>> -Markus
>>>
>>> -----Original Message-----
>>> From: Bill Burke [mailto:bburke_at_redhat.com]
>>> Sent: Mittwoch, 21. Januar 2015 15:56
>>> To: jsr370-experts_at_jax-rs-spec.java.net
>>> Subject: Re: JAX-WS like Provider in JAX-RS
>>>
>>> BTW, you wouldn't need @DefaultMethod if the matching algorithm wasn't broken....For example, a sane matching algorithm would allow this:
>>>
>>> @Path("/{wildcard:.*}")
>>> public class DefaultOptionsBehavior {
>>>
>>> @OPTIONS
>>> public Response handleOption() {
>>> }
>>> }
>>>
>>> But, unfortunately, as I've complained about over and over again, the matching algorithm doesn't support backtracking after failing to resolve the call with a more specific resource class. The TCK enforces this broken behavior too...SO...we're stuck with discussing @DefaultMethod.
>>>
>>> On 1/21/2015 9:14 AM, Marcos Luna wrote:
>>>> Actually the http methods are 7 acording with the http 1.1
>>>> specification, the default method should react to all of them? or a
>>>> specific default method for each one is a better idea? Something like
>>>>
>>>> interface ServiceProvider {
>>>> Response invokePOST(InputStream is);
>>>> Response invokeDELETE(InputStream is); Response invokeGET(InputStream
>>>> is); ...
>>>> }
>>>> Just an idea.
>>>>
>>>> If non annotated rest API will be available to manage non anotated
>>>> operations, I think it should be very specific on the behavior of the
>>>> available methods. So if you accept DELETE actions, you can separate
>>>> those calls from the most common GET actions and do your updates and
>>>> respond accordingly to each of your REST services if no method is
>>>> defined to handle it.
>>>> Leaving a single default method can lead to bad habits like manage
>>>> all your different request methods from a single point and you end
>>>> with a mess of conditions.
>>>> --
>>>> Marcos
>>>> --------------
>>>> Marcos Luna Yela
>>>> *Sent:* Tuesday, January 20, 2015 at 12:47 PM
>>>> *From:* "Santiago Pericas-Geertsen"
>>>> <Santiago.PericasGeertsen_at_oracle.com>
>>>> *To:* jsr370-experts_at_jax-rs-spec.java.net
>>>> *Subject:* Re: JAX-WS like Provider in JAX-RS
>>>>
>>>> > On Jan 16, 2015, at 5:29 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>>> >
>>>> > IMO, many of us continue to think of JAX-RS as Servlet.nextgen
>>>> rather than a REST framework. Spec leads should really decide the direction here.
>>>>
>>>> Personally, I don’t see these two views as mutually exclusive for
>>>> JAX-RS. Especially when there often isn’t universal agreement on
>>>> certain APIs being truly RESTful or not. Ultimately, it comes down to
>>>> solving real-world problems, and in that context, I can see the
>>>> benefit of @DefaultMethod.
>>>>
>>>> — Santiago
>>>>
>>>> >
>>>> > On 1/16/2015 5:11 PM, Sergey Beryozkin wrote:
>>>> >> Ha-Ha :-)
>>>> >>
>>>> >> The difference is JAX-RS has a richer context support. The
>>>> JAX-RS
>>>>>> filters would still be there.
>>>> >> Something like @DefaultMethod, as Markus suggested, or something
>>>>>> similar, can work in principle.
>>>> >> I guess it is a weak case so far, I'll see how it goes in my
>>>> current >> project, perhaps some more ideas may arise...
>>>> >>
>>>> >> Sergey
>>>> >> On 16/01/15 19:30, Bill Burke wrote:
>>>> >>> Isn't there some specification in Java EE that allows you to do
>>>> this for >>> HTTP? I'm pretty sure Java EE has a non-annotated api
>>>> for Java EE.
>>>> >>> Anybody know what it is? ;)
>>>> >>>
>>>> >>> On 1/16/2015 11:10 AM, Sergey Beryozkin wrote:
>>>> >>>> Hi All,
>>>> >>>>
>>>> >>>> Happy New Year,
>>>> >>>>
>>>> >>>> I've seen a number of times users asking how to have a dynamic
>>>> JAX-RS >>>> service which would support various HTTP methods but
>>>> without having to >>>> annotate. Something like JAX-WS Provider [1].
>>>> >>>>
>>>> >>>> How about introducing javax.ws.rs.ServiceProvider interface:
>>>> >>>>
>>>> >>>> interface ServiceProvider {
>>>> >>>> Response invoke(InputStream is); >>>> } >>>> >>>> The
>>>> implementation can inject a JAX-RS Request context and get an HTTP
>>>>>>>> verb name. UriInfo context will provide all the info about the
>>>> request >>>> URI including path and query parameters, HttpHeaders - about headers.
>>>> >>>> The injected Providers interface will help to read the stream
>>>> into some >>>> concrete object for Post/Put requests if needed.
>>>> >>>>
>>>> >>>> If a given object implements ServiceProvider then the JAX-RS
>>>>>>>> implementation will accept it as a service bean. @Path is
>>>> defaulted to >>>> "" if no @Path is available.
>>>> >>>>
>>>> >>>> I think it can be introduced into a spec (API, text) fairly
>>>> easy but I'm >>>> not expecting this proposal accepted easily too.
>>>> >>>>
>>>> >>>> Any comments ?
>>>> >>>>
>>>> >>>> Sergey
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> [1]
>>>> http://docs.oracle.com/javase/7/docs/api/javax/xml/ws/Provider.html
>>>> >>>
>>>> >>
>>>> >
>>>> > --
>>>> > Bill Burke
>>>> > JBoss, a division of Red Hat
>>>> > http://bill.burkecentral.com
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com