Hi Santiago
That would be fine indeed.
I was just thinking that one side-effect might be that WADL/etc auto
generators would have problems getting enough info out of it. But the
same is the case for Path wildcards. So well may be it is a minor issue.
In principle this annotation if it were to be introduced could have a
'verbs' attributes restricting to supporting a limited array of verbs
but also providing some type info. But I'm not proposing to do it now
for sure. Not a problem if a description of some sort is provided
independently
Sergey
On 22/01/15 17:47, Santiago Pericas-Geertsen wrote:
>
>> On Jan 22, 2015, at 11:29 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>>
>> Hi Santiago
>>
>> I was actually planning to suggest a 3.a update in the JIRA comment but then thought that having a minor subsection on DefaultMethod earlier on was sufficient, the 3.a "request method is supported" would be satisfied by the text in that subsection that a resource method with this annotation is effectively an HTTP verb wild-card.
>
> If we agree on this feature, I rather update the algorithm section to accommodate this change; better to keep that section self contained —it is hard as it is to follow it to include references to other sections. The Javadoc for the new annotation could provide the rest.
>
> — Santiago
>
>>
>> I subsequently modified my comment and one extra spec text requiment that indeed more specific methods are preferred, this would only apply to methods which have already passed the same path and media type checks:
>>
>> @GET
>> @Path("/a")
>> @Produces(text/xml)
>> Response get();
>>
>> @DefaultMethod
>> @Path("/a")
>> @Produces(text/xml)
>> Response all();
>>
>> get() wins.
>>
>> I'm working on the same extension in CXF, not the first time I need an extension :-). Note I do need it right now for a more esoteric requirement but I've become quite convinced it would help some users who asked me on our users list and also in some of the cases listed in JIRA. As far as I'm concerned it is a minor enhancement request so will take it fine if it proves to be not accepted in the end...Just hoping for now our extension will stay as the extension as such only for the next couple of years :-)
>>
>> Sergey
>>
>>
>>
>> On 22/01/15 14:24, Santiago Pericas-Geertsen wrote:
>>> Sergey,
>>>
>>> At first glance, I think this would require some changes to (3a) and (3b) in the matching algorithm. The former, to avoid filtering these methods; the later to ensure an ordering in which @GET, etc. is preferred over @DefaultMethod.
>>>
>>> — Santiago
>>>
>>>> On Jan 22, 2015, at 7:32 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>>>>
>>>> Hi All:
>>>>
>>>> https://java.net/jira/browse/JAX_RS_SPEC-507
>>>>
>>>> Note I'd like to stress that this is exactly what I meant, having a resource method HTTP method annotation that matches any HTTP method.
>>>>
>>>> No plan there to have it used for matching any otherwise failed matches.
>>>> It is not a workaround against the perceived limitations of the selection algorithm to do with supporting paths or media types.
>>>>
>>>> Example, if I have a @DefaultMethod on @Path("a") then no way it will get a selection if it is a "/b" request.
>>>>
>>>> IMHO it is indeed rather interesting to examine the possibility of supporting a default handler that would be invoked should a selection algorithm fail to match any resource method but IMHO it would be better if such an option is discussed in a separate thread.
>>>>
>>>> It is a simple enhancement request which may help in some cases.
>>>>
>>>> Thanks, Sergey
>>>>
>>>> On 21/01/15 22:01, Sergey Beryozkin wrote:
>>>>> Hi Santiago
>>>>>
>>>>> I'll open a Minor JIRA issue shortly
>>>>>
>>>>> Sergey
>>>>> On 21/01/15 20:34, Santiago Pericas-Geertsen wrote:
>>>>>> All,
>>>>>>
>>>>>> Seems to me that Markus and Sergey are thinking along the same lines
>>>>>> as to what could be done here. Would it be possible for the two of you
>>>>>> to sync up and provide a single proposal?
>>>>>>
>>>>>> It should be easy to integrate into the existing algorithm and,
>>>>>> hopefully, possible to describe in a couple of sentences.
>>>>>>
>>>>>> — Santiago
>>>>>>
>>>>>>> On Jan 21, 2015, at 12:40 PM, Markus KARG <markus_at_headcrashing.eu
>>>>>>> <mailto:markus_at_headcrashing.eu>> wrote:
>>>>>>>
>>>>>>> First of all, it is impossible to use named path parameters if you do
>>>>>>> not have an annotation. Using @DefaultMethod("{path}") it is. Hence,
>>>>>>> not using annotations reduces the number of useable features.
>>>>>>> Second, RFC 2616 chapter 9's introduction clearly says that the set of
>>>>>>> methods is infinite, not statically 7. Hence the annotations are
>>>>>>> needed to defined the routing from http method to Java method. In some
>>>>>>> cases, it makes sense to share a common implementation, or to catch
>>>>>>> unclear routing information. This is what @DefaultMethod would allow
>>>>>>> to do. It is implicitly impossible to route multiple http methods to
>>>>>>> the same fallback method in your proposal. What you propose is not
>>>>>>> "default routing" to catch-all (which is the idea behind
>>>>>>> @DefaultMethod) but you propose "default names" to get rid of
>>>>>>> annotations (which is not a target of JAX-RS revisions AFAIK). Your
>>>>>>> proposal is more or less already covered behind my proposal of
>>>>>>> december 2009 (https://java.net/jira/browse/JAX_RS_SPEC-18) already.
>>>>>>> Did you check that before?
>>>>>>> *From:*Marcos Luna [mailto:marcos.luna_at_email.com]
>>>>>>> *Sent:*Mittwoch, 21. Januar 2015 15:15
>>>>>>> *To:*jsr370-experts_at_jax-rs-spec.java.net
>>>>>>> <mailto:jsr370-experts_at_jax-rs-spec.java.net>
>>>>>>> *Subject:*Re: JAX-WS like Provider in JAX-RS
>>>>>>> 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
>>>>>>> <mailto:Santiago.PericasGeertsen_at_oracle.com>>
>>>>>>> *To:* jsr370-experts_at_jax-rs-spec.java.net
>>>>>>> <mailto: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
>>>>>>> <mailto: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 <http://bill.burkecentral.com/>
>>>>>>
>>>>>
>>>>
>>>
>>
>