[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251196#comment-16251196
]
Sergey Beryozkin edited comment on CXF-7544 at 11/14/17 10:26 AM:
------------------------------------------------------------------
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 interfaces 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
was (Author: sergey_beryozkin):
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)
