[jira] [Created] (CXF-7571) Revamp of the CXF injection implementation
Andriy Redko created CXF-7571: - Summary: Revamp of the CXF injection implementation Key: CXF-7571 URL: https://issues.apache.org/jira/browse/CXF-7571 Project: CXF Issue Type: Improvement Reporter: Andriy Redko Assignee: Andriy Redko As more deep integration with CDI revealed, there are complexities in bringing together `@Context`- and `@Inject`-based injections. Encapsulating CXF injection implementation and than delegating the hard work to appropriate strategy (CDI, Spring, ...) would be the right solution to address the problem at its root. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265847#comment-16265847
]
ASF GitHub Bot commented on CXF-7544:
-
reta opened a new pull request #346: CXF-7544: Support @Context-based injection
into proxied CDI beans
URL: https://github.com/apache/cxf/pull/346
The issue pop up as part of #330 discussion. In case when provider / feature
/ resource is a proxied CDI bean, the contextual class members (annotated with
@context) are not injected.
More broadly, 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).
@johnament @rmannibucau 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, provifing custom `@Context` injectors. The
good news is that the field-based injection could be easily workarounded using
setter-based injection. After conversations with @sberyozkin, we decided that
encapsulating CXF injection implementation and than delegating the hard work to
appropriate strategy (CDI, Spring, ...) would be better time investment than
trying to patch the existing one. Since we have simple workaround, it sounds
like an acceptable tradeoff (https://issues.apache.org/jira/browse/CXF-7571).
This PR fixes the patterns in `CdiClassUnwrapper`, adds tests for it and
fixes the `FilterProviderInfo` resource / service class resolution (to match it
to the `ProviderInfo`)
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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
> observ
[jira] [Updated] (CXF-7571) Revamp of the CXF injection implementation
[ https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-7571: -- Description: As more deep integration with CDI revealed, there are complexities in bringing together `@Context`- and `@Inject`-based injections. Encapsulating CXF injection implementation and than delegating the hard work to appropriate strategy (CDI, Spring, ...) would be the right solution to address the problem at its roots. (was: As more deep integration with CDI revealed, there are complexities in bringing together `@Context`- and `@Inject`-based injections. Encapsulating CXF injection implementation and than delegating the hard work to appropriate strategy (CDI, Spring, ...) would be the right solution to address the problem at its root.) > Revamp of the CXF injection implementation > --- > > Key: CXF-7571 > URL: https://issues.apache.org/jira/browse/CXF-7571 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko > > As more deep integration with CDI revealed, there are complexities in > bringing together `@Context`- and `@Inject`-based injections. Encapsulating > CXF injection implementation and than delegating the hard work to appropriate > strategy (CDI, Spring, ...) would be the right solution to address the > problem at its roots. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265848#comment-16265848
]
ASF GitHub Bot commented on CXF-7544:
-
reta commented on a change in pull request #346: CXF-7544: Support
@Context-based injection into proxied CDI beans
URL: https://github.com/apache/cxf/pull/346#discussion_r153054114
##
File path:
rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/ServerProviderFactory.java
##
@@ -211,7 +211,11 @@ protected void setProviders(boolean custom, boolean
busGlobal, Object... provide
for (Object featureProvider : cfg.getInstances()) {
Map, Integer> contracts =
cfg.getContracts(featureProvider.getClass());
if (contracts != null && !contracts.isEmpty()) {
-allProviders.add(new
FilterProviderInfo(featureProvider,
+Class providerCls =
ClassHelper.getRealClass(getBus(), featureProvider);
Review comment:
Turned out we handle `ProviderInfo` differently than `FilterProviderInfo`,
this minors fixes will match the resource and service class resolution.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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)
[jira] [Updated] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
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}
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 rece
[jira] [Updated] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
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
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265885#comment-16265885
]
ASF GitHub Bot commented on CXF-7544:
-
reta commented on a change in pull request #346: CXF-7544: Support
@Context-based injection into proxied CDI beans
URL: https://github.com/apache/cxf/pull/346#discussion_r153054114
##
File path:
rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/ServerProviderFactory.java
##
@@ -211,7 +211,11 @@ protected void setProviders(boolean custom, boolean
busGlobal, Object... provide
for (Object featureProvider : cfg.getInstances()) {
Map, Integer> contracts =
cfg.getContracts(featureProvider.getClass());
if (contracts != null && !contracts.isEmpty()) {
-allProviders.add(new
FilterProviderInfo(featureProvider,
+Class providerCls =
ClassHelper.getRealClass(getBus(), featureProvider);
Review comment:
Turned out we handle `ProviderInfo` differently than `FilterProviderInfo`,
these minors fixes will match the resource and service class resolution.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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;
> }
>
> @Over
