Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jaxrs-dev] CDI resource classes and lifecycle
Thanks John, I have never looked at the CXF code. I just asumed bean discovery "all" would convert all to dependent beans. The WildFly case is due to special code for discovery "annotated".

I'm aware of the CDI constraint on bean defning annotations. I in fact created a CDI issue related to that (https://issues.jboss.org/browse/CDI-701) precisely cause I needed a portable way to make all JAX-RS resources beans, with dicovery mode annotated :). Sadly neither it nor the discussed JAX-RS integration with CDI took place at that time.

El lun., 9 abr. 2018 20:48, John D. Ament <john.d.ament@xxxxxxxxx> escribió:
On Mon, Apr 9, 2018 at 2:37 PM Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
Hi,

Are you using WildFly for a chance?

The general interpretation is that resources might be used as CDI beans, but the user has to explictly make them beans, i.e.: the behavior you are seeing is not standard.

WildFly has some useful propietary code that converts the @Path annotation into a bean annotation so that a CDI extension on Resteasy can detect them and automatically make beans from them (although @RequestScoped IIRC).

Another possibility is that you are using bean discovery mode all, but with bean annotated mode e.g. Payara doesn't detect them.

You should also look at how CXF works, to better see the discrepancies.

RestEasy's CDI extension adds RequestScoped to any resource that has no scope defined.  CXF does not do this, instead it honors dependent and creates a new instance per invocation (and destroys it when done, per the spec).

The problem is that CDI does not allow discovery of beans that are not annotated in some way.  Due to this, if you mix this setup with bean-discovery-mode=annotated or all w/ trim option, then the container also has to consider the fallback strategy where the resource has no CDI beans behind it, and instead instantiate it manually.  This also means that these extensions that add the scope won't see the class to properly add the scope.
 

El lun., 9 abr. 2018 20:23, Christian Kaltepoth <christian@xxxxxxxxxxxx> escribió:
Hi all,

I've a question regarding CDI and the lifecycle of resource classes.

The JAX-RS spec states:
  • 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:

  @Path("/cdibean")
  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.

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.

Any thoughts? Or is it just me having doubts about this? :-)

Christian

--
Christian Kaltepoth

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

Back to the top