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

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

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

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