MVC 1.0 vs CDI

[Christian Kaltepoth]

Hi all,

as most of you know, I'm currently working on the TCK. While working on the tests for chapter 2, a few questions came up.

The spec states:

• "Unlike in JAX-RS [...], MVC classes are REQUIRED to be CDI-managed beans only"
  
• "Like in JAX-RS, the default resource class instance lifecycle is per-request"

These requirements seems to be simple and straight forward, but the devil is in the details:

• Is the MVC implementation required to enforce that controllers are CDI beans, or is the user responsible for this?
• If the user has to ensure the controller is a CDI bean, should the MVC implementation fail the deployment if a controller is not a CDI bean?
• If the MVC implementation is responsible for making all controllers CDI beans, implementations could write a CDI extension which enforces this.
• The RI currently does nothing regarding this. So if you use CDI with discovery-mode="annotated" and don't use a bean-defining annotation on your controller, @Inject won't work and you will run into NPEs
• The default lifecycle of a resource class is per-request:
• The RI doesn't do anything to enforce this.
• I'm not sure how JAX-RS handles this requirement. By default, CDI beans are @Dependent scoped and not @RequestScoped. Does JAX-RS modify the scope of CDI-based resources at deployment time? Or is @Dependent and @RequestScoped basically the same in JAX-RS?

Many question. Any thoughts?

Christian

--

Christian Kaltepoth

Blog: http://blog.kaltepoth.de/

Twitter: http://twitter.com/chkal

GitHub: https://github.com/chkal

[Ivar Grimstad]

Hi,

My view on this is that the MVC implementations should be responsible for enforcing that the controllers are CDI beans.

If, or when, JAX-RS embraces CDI, this will be provided for us out of the box. In the meantime, the users of MVC should be shielded from this and not be forced to clutter their code with CDI-scope annotations or a beans.xml

Ivar

--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com.
To post to this group, send email to jsr371...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/CAEXeC6znCK55oTqiq2d3ML%2BbXzj-0zefsjqfxPT2%3DGC-KiZoPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader

[Santiago Pericas-Geertsen]

Christian,

 With CDI enabled, what the spec states should be the default behavior on all JAX-RS implementations (whether it actually is, I don’t know for sure :). Per-request/@RequestScoped is the default scope in JAX-RS for resource classes.

 

 I believe the @Dependent default scope only makes sense while injecting a bean in the context of another CDI bean, which is not the case for resource classes that are instantiated by the JAX-RS/MVC implementation.

— Santiago

To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/CAOAQAPrzLb6sQR1gAN-rJpYMdaFc%3D8D%3Dq6Pf8A-NuT2Skw4-iQ%40mail.gmail.com.

[Christian Kaltepoth]

Hi Ivar,

thanks for your comment. So you think that the MVC implementation should be responsible for registering controllers correctly with the CDI container if required? Did I get this right?

This would mean something like:

• If the MVC controller is not a CDI bean (= no scope annotation + bean-discovery-mode="annotated"), the MVC implementation should register the controller with the CDI container automatically so that @Inject works correctly
• If the MVC controller does not have a scope annotation (which means that it is dependent scoped), the MVC implementation should change the scope to @RequestScoped via a CDI extension

Is that correct?

Christian

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/CAOAQAPrzLb6sQR1gAN-rJpYMdaFc%3D8D%3Dq6Pf8A-NuT2Skw4-iQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[Christian Kaltepoth]

Hi Santiago,

thanks a lot for sharing your thoughts on this. See my reply inline.

With CDI enabled, what the spec states should be the default behavior on all JAX-RS implementations (whether it actually is, I don’t know for sure :). Per-request/@RequestScoped is the default scope in JAX-RS for resource classes.

That's not entirely correct. I agree that the JAX-RS spec states that non-CDI resources should be created per request. No doubt about that.

However, the JAX-RS spec doesn't say anything about the required scope if the resource is a CDI bean. So the default scope for CDI applies, which is @Dependent. I just checked this on Glassfish 5. CDI resources are dependent-scoped if no other scope annotation is added to the resource. If the default scope for CDI-based JAX-RS resources should be @RequestScoped, the JAX-RS implementation would need to change that using a CDI extension, but that doesn't seem to be the case.

 

I believe the @Dependent default scope only makes sense while injecting a bean in the context of another CDI bean, which is not the case for resource classes that are instantiated by the JAX-RS/MVC implementation.

I agree. However, my guess is that JAX-RS implementations typically lookup the resource from the CDI container once and then use this instance thought the full request processing lifecycle. In this case the resource will be created once and it will behave just like a @RequestScoped bean, although it is in fact @Dependent scoped.

Christian

[Christian Kaltepoth]

Santiago,

I also posted my question about CDI resources and their lifecycle on the jaxrs-dev list. For some reason the mail just showed up on the list, although I sent it a few days ago. Maybe the JAX-RS related discussion should be continued there!?

Thanks a lot

Christian

[Santiago Pericas-Geertsen]

On Apr 9, 2018, at 2:21 PM, Christian Kaltepoth <chri...@kaltepoth.de> wrote:

Hi Santiago,

thanks a lot for sharing your thoughts on this. See my reply inline.

With CDI enabled, what the spec states should be the default behavior on all JAX-RS implementations (whether it actually is, I don’t know for sure :). Per-request/@RequestScoped is the default scope in JAX-RS for resource classes.

That's not entirely correct. I agree that the JAX-RS spec states that non-CDI resources should be created per request. No doubt about that.

 The spec does not make that distinction, it just says that resource classes by default should be one per request. That should apply to CDI beans as well.

However, the JAX-RS spec doesn't say anything about the required scope if the resource is a CDI bean. So the default scope for CDI applies, which is @Dependent. I just checked this on Glassfish 5. CDI resources are dependent-scoped if no other scope annotation is added to the resource. If the default scope for CDI-based JAX-RS resources should be @RequestScoped, the JAX-RS implementation would need to change that using a CDI extension, but that doesn't seem to be the case.

 

I believe the @Dependent default scope only makes sense while injecting a bean in the context of another CDI bean, which is not the case for resource classes that are instantiated by the JAX-RS/MVC implementation.

I agree. However, my guess is that JAX-RS implementations typically lookup the resource from the CDI container once and then use this instance thought the full request processing lifecycle. In this case the resource will be created once and it will behave just like a @RequestScoped bean, although it is in fact @Dependent scoped.

 @Dependent with respect to what? If w.r.t to a @RequestScope bean, it would be fine.

— Santiago

[Christian Kaltepoth]

Hi Santiago,

 The spec does not make that distinction, it just says that resource classes by default should be one per request. That should apply to CDI beans as well.

I agree that this should apply to CDI as well. Maybe this should be a bit more explicit in the CDI chapter of the JAX-RS spec.

 

 @Dependent with respect to what? If w.r.t to a @RequestScope bean, it would be fine.

Well, a CDI-based JAX-RS resource is managed by the CDI runtime and therefore has exactly one scope. And according to my tests with Glassfish CDI-based JAX-RS resources are @Dependent scoped.

But I agree that this may not be a problem in practice, because a resource is requested from the JAX-RS implementation only once per request and therefore behaves just like a @RequestScoped bean.

Christian