[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans

["Sergey Beryozkin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251196#comment-16251196 ] 

Sergey Beryozkin commented on CXF-7544:
---------------------------------------

Hi Andriy, 
Can you please first check if a CDIClassUnwrapper idea works as suggested by John ?

FYI, in case of Spring proxies, I've been always recommending users to simply create an interface, example, with the code above in mind, it would be something like this:
{code:java}
interface Injectable {
  @Context
  public setResourceInfo(ResourceInfo resourceInfo);
}

public class BookStoreRequestFilter implements ContainerRequestFilter, Injectable {
    private ResourceInfo resourceInfo;
    public setResourceInfo(ResourceInfo resourceInfo) {
        this.resourceInfo = resourceInfo;
    }
    
}

{code}

and it has always worked, the interface are always retained during the proxification. Can you try this as well ?

Seeing a POC branch would be interesting :-), and indeed having the CXF JAX-RS itself not to deal with the injection 'manually' would be nice, though I agree it is the kind of change that perhaps should go to the next/new CXF master 

Thanks

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



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