cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andriy Redko (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CXF-7544) Support @Context-based injection into proxied CDI beans
Date Sat, 25 Nov 2017 21:03:00 GMT

     [ https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andriy Redko updated CXF-7544:
------------------------------
    Description: 
The issue pop up as part of https://github.com/apache/cxf/pull/330 discussion. In case when
provider / feature / resource is a proxied CDI bean, the contextual class members (annotated
with @Context) are not injected.

Test case to reproduce:

{code}
@ApplicationScoped
public class BookStoreRequestFilter implements ContainerRequestFilter {
    @Context private ResourceInfo resourceInfo;
    
    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        // Contextual instances should be injected independently
        if (resourceInfo == null || resourceInfo.getResourceMethod() == null) {
            requestContext.abortWith(Response.serverError().build());
        }
    }
}
{code}

CC [~rmannibucau]

h3. A bit more context 

In some circumstances (like using @ApplicationScoped annotation for example) the CDI runtime
will create a proxy class for a particular bean. As the result, the CXF side is going to bind
the particular provider metadata to this proxy instance. It looks logical and unambiguous.

However, the interesting things are happening when CXF will try to inject contextual proxies
(@Context annotations) into the provider instance. The injections are successful but the target
object for them will be the proxy instance (not the real instance behind it). Consequently,
at runtime, when the proxy delegates the call to a backing instance, all contextual proxies
are null in there (simply put, not set).

h3. How to solve 

Referring to the recent discussions with [~sergeyb], the best solution would be to delegate
the @Context annotation to CDI framework (as such, relieving the CXF from doing the injection
work). This proposal may need a support from the JAX-RS specification side.

Simpler (interim?) possible solution would be to complement the CDI injection with @Context
injection (delegating this work to the CXF as it works right now for non-proxy beans and non-CDI
deployments). This could be done by observing ProcessInjectionTarget events and supplying
our own InjectionTarget (have working PoC for this approach).

Regarding constructor injection, it seems like CXF does not support passing the arguments
to provider constructor (in case of CDI, w/o @Context annotation) so I it would be another
(separate) issue to look at.

h3. Update
Addressing the issue requires a significant revamp of the CXF injection mechanism, it is turned
out to be hard to solve even with @AroundConstruct or, previously, providing custom @Context
injectors. The good news is that the field-based injection could be easily workarounded using
setter-based injection. 

{code}
@ApplicationScoped
public class BookStoreRequestFilter implements ContainerRequestFilter {
    private ResourceInfo resourceInfo;
    
    @Context 
    public void setResourceInfo(ResourceInfo resourceInfo) {
        this.resourceInfo = resourceInfo;
    }
    
    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        // Contextual instances should be injected independently
        if (resourceInfo == null || resourceInfo.getResourceMethod() == null) {
            requestContext.abortWith(Response.serverError().build());
        }
    }
}
{code}

The work related to CXF injection refactoring is tracked under CXF-7571

  was:
The issue pop up as part of https://github.com/apache/cxf/pull/330 discussion. In case when
provider / feature / resource is a proxied CDI bean, the contextual class members (annotated
with @Context) are not injected.

Test case to reproduce:

{code}
@ApplicationScoped
public class BookStoreRequestFilter implements ContainerRequestFilter {
    @Context private ResourceInfo resourceInfo;
    
    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        // Contextual instances should be injected independently
        if (resourceInfo == null || resourceInfo.getResourceMethod() == null) {
            requestContext.abortWith(Response.serverError().build());
        }
    }
}
{code}

CC [~rmannibucau]

h3. A bit more context 

In some circumstances (like using @ApplicationScoped annotation for example) the CDI runtime
will create a proxy class for a particular bean. As the result, the CXF side is going to bind
the particular provider metadata to this proxy instance. It looks logical and unambiguous.

However, the interesting things are happening when CXF will try to inject contextual proxies
(@Context annotations) into the provider instance. The injections are successful but the target
object for them will be the proxy instance (not the real instance behind it). Consequently,
at runtime, when the proxy delegates the call to a backing instance, all contextual proxies
are null in there (simply put, not set).

h3. How to solve 

Referring to the recent discussions with [~sergeyb], the best solution would be to delegate
the @Context annotation to CDI framework (as such, relieving the CXF from doing the injection
work). This proposal may need a support from the JAX-RS specification side.

Simpler (interim?) possible solution would be to complement the CDI injection with @Context
injection (delegating this work to the CXF as it works right now for non-proxy beans and non-CDI
deployments). This could be done by observing ProcessInjectionTarget events and supplying
our own InjectionTarget (have working PoC for this approach).

Regarding constructor injection, it seems like CXF does not support passing the arguments
to provider constructor (in case of CDI, w/o @Context annotation) so I it would be another
(separate) issue to look at.

h3. Update
Addressing the issue requires a significant revamp of the CXF injection mechanism, it is turned
out to be hard to solve even with @AroundConstruct or, previously, providing custom @Context
injectors. The good news is that the field-based injection could be easily workarounded using
setter-based injection. 

{code}
@ApplicationScoped
public class BookStoreRequestFilter implements ContainerRequestFilter {
    private ResourceInfo resourceInfo;
    
    @Context 
    public void setResourceInfo(ResourceInfo resourceInfo) {
        this.resourceInfo = resourceInfo;
    }
    
    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        // Contextual instances should be injected independently
        if (resourceInfo == null || resourceInfo.getResourceMethod() == null) {
            requestContext.abortWith(Response.serverError().build());
        }
    }
}
{code}




> Support @Context-based injection into proxied CDI beans
> -------------------------------------------------------
>
>                 Key: CXF-7544
>                 URL: https://issues.apache.org/jira/browse/CXF-7544
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 3.1.13, 3.2.0
>            Reporter: Andriy Redko
>            Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330 discussion. In case
when provider / feature / resource is a proxied CDI bean, the contextual class members (annotated
with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
>     @Context private ResourceInfo resourceInfo;
>     
>     @Override
>     public void filter(ContainerRequestContext requestContext) throws IOException {
>         // Contextual instances should be injected independently
>         if (resourceInfo == null || resourceInfo.getResourceMethod() == null) {
>             requestContext.abortWith(Response.serverError().build());
>         }
>     }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context 
> In some circumstances (like using @ApplicationScoped annotation for example) the CDI
runtime will create a proxy class for a particular bean. As the result, the CXF side is going
to bind the particular provider metadata to this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject contextual
proxies (@Context annotations) into the provider instance. The injections are successful but
the target object for them will be the proxy instance (not the real instance behind it). Consequently,
at runtime, when the proxy delegates the call to a backing instance, all contextual proxies
are null in there (simply put, not set).
> h3. How to solve 
> Referring to the recent discussions with [~sergeyb], the best solution would be to delegate
the @Context annotation to CDI framework (as such, relieving the CXF from doing the injection
work). This proposal may need a support from the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection with @Context
injection (delegating this work to the CXF as it works right now for non-proxy beans and non-CDI
deployments). This could be done by observing ProcessInjectionTarget events and supplying
our own InjectionTarget (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing the arguments
to provider constructor (in case of CDI, w/o @Context annotation) so I it would be another
(separate) issue to look at.
> h3. Update
> Addressing the issue requires a significant revamp of the CXF injection mechanism, it
is turned out to be hard to solve even with @AroundConstruct or, previously, providing custom
@Context injectors. The good news is that the field-based injection could be easily workarounded
using setter-based injection. 
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
>     private ResourceInfo resourceInfo;
>     
>     @Context 
>     public void setResourceInfo(ResourceInfo resourceInfo) {
>         this.resourceInfo = resourceInfo;
>     }
>     
>     @Override
>     public void filter(ContainerRequestContext requestContext) throws IOException {
>         // Contextual instances should be injected independently
>         if (resourceInfo == null || resourceInfo.getResourceMethod() == null) {
>             requestContext.abortWith(Response.serverError().build());
>         }
>     }
> }
> {code}
> The work related to CXF injection refactoring is tracked under CXF-7571



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message