[
https://issues.apache.org/jira/browse/CXF-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755724#comment-17755724
]
Andriy Redko edited comment on CXF-8911 at 8/17/23 10:38 PM:
-------------------------------------------------------------
Hey [~dufoli] ,
I haven't had time to get back to the issue, apologies, but there was only one
problem I stumbled upon related to CXFResponseCallback, the default one
(current) calls the {color:#000000}setHttpResponse(..) method of the outer
{color}{color:#000000}AsyncWrappedOutputStream{color} instance:
{noformat}
CXFResponseCallback responseCallback = new CXFResponseCallback() {
@Override
public void responseReceived(HttpResponse response) {
setHttpResponse(response);
}
};{noformat}
It has to be done and there if we replace the CXFResponseCallback with factory,
there is no way to enforce the default behavior (and we don't the client will
hang forever).
was (Author: reta):
Hey [~dufoli] ,
I haven't had time to get back to the issue, apologies, but there was only one
problem stumbled upon related to CXFResponseCallback, the default one
(current) calls the {color:#000000}setHttpResponse(..) method of the outer
{color}{color:#000000}AsyncWrappedOutputStream{color} instance:
{noformat}
CXFResponseCallback responseCallback = new CXFResponseCallback() {
@Override
public void responseReceived(HttpResponse response) {
setHttpResponse(response);
}
};{noformat}
It has to be done and there if we replace the CXFResponseCallback with factory,
there is no way to enforce the default behavior (and we don't the client will
hang forever).
> Allow creating a custom CXFHttpAsyncResponseConsumer
> ----------------------------------------------------
>
> Key: CXF-8911
> URL: https://issues.apache.org/jira/browse/CXF-8911
> Project: CXF
> Issue Type: New Feature
> Reporter: Peter Palaga
> Priority: Major
>
> We recently got a [bug
> report|https://github.com/quarkiverse/quarkus-cxf/issues/947] in Quarkus CXF
> complaining about non-working context propagation with CXF HC5 client.
> The problem was that if the client is called in context of a Quarkus REST
> endpoint, whose vert.x thread has the request context setup properly, the
> request scoped beans are then not accessible e.g. from
> ContainerRequestFilters which run in in a different thread.
> To make it work, we would need wrap the creation of
> CXFHttpAsyncResponseConsumer in some code storing the context of the creation
> thread into a wrapping method that can then be executed by some other thread.
> I was able to do this by overriding some default classes. What I did can be
> seen around here:
> https://github.com/quarkiverse/quarkus-cxf/pull/950/files#diff-568a3d75d004f9f41c6130854755ebb2beae2f30308cc45aa98492d09bac2ecc
> This solution is by no means elegant and I wonder whether it would be
> feasible to implement some new API to allow creating custom
> CXFHttpAsyncResponseConsumers?
> Maybe we could introduce some kind of CXFHttpAsyncResponseConsumerFactory?
> I am quite new to CXF internals, so I'd be thankful for any hints how to
> proceed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
