users@jsr311.java.net

Re: What is the standard behavior when injecting property on a singleton resource class?

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Mon, 21 Jul 2014 15:29:50 +0200

Hello,

(rerouting your request to users_at_jax-rs-spec.java.net and dropping the JSR311 mailing lists via BCC.)

On 21 Jul 2014, at 14:56, Grant Yang <grantsunny_at_msn.com> wrote:

> Dear experts,
>
> When discussing the support of field / property injection, especially @Context injection, the spec document seems lack of details on the part of support singleton resource classes (either returned from Application.getSingletons() or annotated with @Singleton).
>
> 1. The spec explicitly mentioned that for non-per-request resource classes, support of field / property injection is not supported, but saying "with the exception of @Context". However for @Context, there are also request scope values (UriInfo, Request, HttpHeaders, SecurityContext) and non-scope (Application, Providers, ResourceContext, Configuration) values. What is the expected way to handle these very request scope values per spec?

As defined in the spec, @Context supports injection of only a limited enumerated set of JAX-RS interfaces. Since these are interfaces, in case of request-scoped values into non-request scope injection points, delegate proxies can be injected. These proxies can, of course, fail to provide information when accessed from outside of a request scope.

>
> 2. How many times the injection shall be done to a singleton resource class? I see in the latest javadoc of Application.getSingleton() saying "Fields and properties of returned instances are injected with their declared dependencies (see Context) by the runtime prior to use." While "prior to use" is not a good way to describe the behavior, as "prior to use on the first request" or "prior to use on every request". The implementation shall inject the value only once or every time a request comes by?

Ideally, injection into instance fields should happen only once, but the JAX-RS spec does not define or enforce this behavior, IIRC.

Marek

>
> Actually when reading Jersey document I see Jersey already got some answer of above questions, but not as part of spec; therefore I wanted to get suggestions from you experts, on which part of complies to the spec, which part shall belong to Jersey implementation specified (but of course can be treated as best practice).
>
> Any comments/suggestions will be more than welcome. Thanks in advance!
> Regards,
> Grant.