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/>
>>
>