[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jaxrs-dev] CDI resource classes and lifecycle
|
Yes, I think that was exactly my misunderstanding. :)
I think the misunderstanding is that JAX-RS's phrase "per request" is not necessarily @RequestScope. CDI can reach the target of request scoping by many ways, using several annotations or even programmatic solutions. JAX-RS does not enforce "@RequestScoped" literally, only "effectively".
-Markus
Thanks everybody for your comments.
I only checked the behavior of Jersey/Glassfish up until now, which is that the resource shown in the example in my original mail ends up to be a @Dependent scoped CDI bean. It is interesting to hear that RESTEasy automatically converts JAX-RS CDI resources into @RequestScoped beans if no other scope annotation is present.
However, I was a bit surprised to see @Dependent scoped CDI resources in Jersey. But I agree with Santiago that this won't be a problem in practice, as long as the JAX-RS resource creates (or looks up) the resource only once per request. So the actual CDI scope for resources isn't that important in practice. I somehow expected to see @RequestScoped resources and therefore brought up this topic to the list for clarification.
Christian,
what do you mean with "weird"? The CDI *default* is @Dependent, but it does *not* apply for JAX-RS resources classes, as JAX-RS explicitly mandates a different scope per the spec, which is @RequestScoped. This means, the JAX-RS implementation (not the user) is responsible to tell CDI that the resource class is request scoped "under the hood".
Maybe I misunderstood your question?
-Markus
Hi all,
I've a question regarding CDI and the lifecycle of resource classes.
- 3.1.1 Lifecycle and Environment:
- "By default a new resource class instance is created for each request to that resource."
- 11.2.3 Context and Dependency Injection (CDI):
- "In a product that supports CDI, implementations MUST support the use of CDI-style Beans as root resource classes"
The example CDI resource in section 11.2.3 looks like this:
public class CdiBeanResource {
@Inject MyOtherCdiBean bean; // CDI injected bean
Please note that the resources doesn't have a scope annotation. In this case CDI will assume @Dependent scope.
The default scope for JAX-RS should be one per request. However that is accomplished in the CDI case is not important.
Isn't this weird? Shouldn't be the default scope for CDI resources be @RequestScoped? Is it up to the user to set the "correct" scope? It is somehow surprising that @Dependent scoped beans work at all because of the way @Dependent is defined.
Given that resource class instances are not injected anywhere, but just created by the implementations, I’m not really sure what @Dependent means in this context. Again, by default, there should be one per request as mandated by the spec.
_______________________________________________
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