Hi Bill
I've no idea why is back tracking introduced into the picture.
It is just a method match only, nothing changes in the spec in
general...(assuming it will be done)
Sergey
On 21/01/15 20:58, Bill Burke wrote:
> 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
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com