Subresource locator - return instance or class
Pavel Bucek
Dear experts, we are in a stage when we are re-reading spec document and javadoc (you're welcomed to help us - if you have some favorite typo anywhere in JAX-RS and you wan't to get rid of it, now is the time to report it) and one particular thing was noticed: specification supports only returning an instance as a subresource, thus:
@Path("sub1") public SubResource getSubResourceLocator1() { return new SubResource(); } is supported and
@Path("sub2") public Class<SubResource> getSubResourceLocator2() { return SubResource.class; } is not. RI currently supports both cases and I'm wondering whether we should add that into the specification. There is obvious advantage of the latter approach, since the instance will be managed (in a correct scope) by the JAX-RS runtime and more importantly, it will be injected, so application developer don't have to inject evertyhing required in a root resource and pass injected values in a constructor of returned instance. What do you think? Thanks and regards,
|
|
Sounds reasonable. If other vendors agree to support this feature, we should add it to the spec.
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Mittwoch, 7. Juni 2017 17:29 To: jaxrs-spec@javaee.groups.io Subject: [jaxrs] Subresource locator - return instance or class
Dear experts, we are in a stage when we are re-reading spec document and javadoc (you're welcomed to help us - if you have some favorite typo anywhere in JAX-RS and you wan't to get rid of it, now is the time to report it) and one particular thing was noticed: specification supports only returning an instance as a subresource, thus: @Path("sub1") public SubResource getSubResourceLocator1() { return new SubResource(); } is supported and @Path("sub2") public Class<SubResource> getSubResourceLocator2() { return SubResource.class; } is not. RI currently supports both cases and I'm wondering whether we should add that into the specification. There is obvious advantage of the latter approach, since the instance will be managed (in a correct scope) by the JAX-RS runtime and more importantly, it will be injected, so application developer don't have to inject evertyhing required in a root resource and pass injected values in a constructor of returned instance. What do you think? Thanks and regards,
|
|
Sergey Beryozkin
Hi Pavel As far as I understand that is what the idea behind ResourceContext.getResource(Class<T>) was ? Thanks, Sergey
On 07/06/17 16:29, Pavel Bucek wrote:
|
|
Pavel Bucek
Hi Sergey, that's true, but does that contradict what we did? (I do see that as a shortcut, which makes sense to have, nothing more).Regards, Pavel
On 13/06/2017 13:33, Sergey Beryozkin
wrote:
|
|
Sergey Beryozkin
Hi Pavel You are right, makes sense Sergey
On 13/06/17 18:57, Pavel Bucek wrote:
|
|