You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Andriy Redko (Jira)" <ji...@apache.org> on 2023/08/17 22:39:00 UTC

[jira] [Comment Edited] (CXF-8911) Allow creating a custom CXFHttpAsyncResponseConsumer

    [ 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)