[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jaxrs-dev] Thoughts on issue #546 (Allow to use @Produces and @Consumes at the Application class)
|
Hi,
I agree with you on the idea of moving the documentation to the Javadoc. We must keep in mind that most people don't even know there's some text out there called "the spec". But we all read the JavaDoc and it's the most natural place for this.
If the specs need to be rewritten finally, this would be a good opportunity to revisit its content.
Hi,
It’s indeed one of the things that seem unclear. I’d personally be a fan of putting as much spec in the Javadoc as feasible, but of course not to the point that it obscures the usage for users of the APIs.
Somewhat more electorate texts can be put in the package java docs.
On Thursday, April 5, 2018, Guillermo González de Agüero <
z06.guillermo@xxxxxxxxx> wrote:
Santiago, do you have any information about expected times for donation of spec texts or how will it even take place?
I read on Twitter Oracle wasn't going to donate the texts, so they will all have to be reworded. I don't know if that's accurate or where did it came from.
Just wondering about it since this issue specifically would need a spec text change.
Regards,
Guillermo González de Agüero
El jue., 5 abr. 2018 8:44, Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx> escribió:
Absolutely +1
Simplicity for developers is very important and this should be also easy to specify and implement.
Ondro
Hi,
Exactly, now it looks for the annotation at method level, and then fallbacks to an anotation at class level. This would fallback again to the annotation at the Application class.
When developers don't specify the available media types, JAX-RS defaults to all, which allows users to request any media type they want, even not available ones. At least on Jersey, requesting an unavailable media types leads to an error response indicating
there's no available MessageBodyWriter for it. Providing an easy way for developers to globally set the used media types mitigates this without having to put the same two annotations on all resources.
Regards,
Guillermo González de Agüero
Hi
Guillermo,
thanks
for bringing this up. So the idea would be to fall back to looking for @Produces / @Consumes on the application class if no corresponding annotation is found on the resource method or class? I basically like the idea. It seems to be a very useful fallback
behavior.
Christian
3.5 @Consumes and @Produces "MAY be applied to a resource method, a resource class, or to an entity provider. [...] In the absence of either of these annotations, support for any media type (“*/*”) is assumed."
Most REST services only allow a specific set of media types (tipically JSON and/or XML). People usually end up having to write the @Consumes("application/json") and @Produces("application/json") on all resources. Annotation inheritance at class level (using
a BaseResource class) is explicitly disabled: 3.6 "Note that inheritance ofclass or interface annotations is not supported."
Therefore I think it should be pretty easy and useful to support putting those annotations on the Application class to determine the default value.
PS: As a side note, if JAX-RS components were CDI beans, this could be easily acomplished by user code via a CDI extension, searching for the annotation on the Application class, and applying that same annotation at runtime to any resource bean not declaring
anything more specific. Just one more point towards CDI integration :)
Regards,
Guillermo González de Agüero
--
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
