Topics

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,
Pavel



 

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,
Pavel

 

 

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:

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,
Pavel




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

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,
Pavel





Sergey Beryozkin
 

Hi Pavel

You are right, makes sense

Sergey

On 13/06/17 18:57, Pavel Bucek wrote:

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

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,
Pavel