[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251431#comment-16251431
]
Sergey Beryozkin commented on CXF-7544:
---------------------------------------
Hey Andriy
First of all thanks for the effort, you are always taking on the tricky issues
:-)
I agree this PR would qualify as an interim solution. I can see the newly added
ServerProviderFactory methods are only called from CDI and they do not affect
the existing logic of the ServerProviderFactory, so it's prob safe enough to
merge even to 3.2.2-SNAPSHOT with the expectations that these
ServerProviderFactory callback methods will be eventually gone.
That said, I'd not hesitate to use another interim solution till a new master
opening soon enough, which us doing nothing and asking users do the interfaces
:-), it works and thus is quite reasonable.
With the new master opening, I'd propose starting with a strategy approach
along these lines: CXF JAX-RS submits all the valid ClassResourceInfos to
InjectionStrategy. It won't CDI/etc calling back, it will be CXF asking the
strategy to inject onto a provided set of classes. As I said the default one
will do what is done now, it will check @Context (fields/constructors) and if
it can see it it will inject. CDI will instead will also check @Inject and may
also delegate to the default one otherwise, etc. We'll have a lot of time to do
it right on the new master. I believe Jersey is doing @Inject of standard
JAX-RS contexts via a similar mechanisms for a while.
> 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)
