[jira] [Commented] (CXF-8303) MP: Context propagation impossible using AsyncInvocationInterceptorFactory
[ https://issues.apache.org/jira/browse/CXF-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138280#comment-17138280 ] Baptiste AIGLIN commented on CXF-8303: -- Hello, no problem, thanks for the answer, and indeed I did not know about the last point specified by the Microprofile spec. However do you think this could do it: * The executor is set by user, so currently it is added to the request context by the MicroProfileClientProxyImpl (l. 131) using EXECUTOR_SERVICE_PROPERTY * This executor is propagated by the AbstractClient#setAsyncMessageObserverIfNeeded (l. ) in the exchange * Then it is used by the HttpConduit#handleResponseOnWorkqueue (l. 1209) to execute the task in this executor. So I find a bit odd that the runnable is still submitted in the cxf work queue, but in the end the execution will be done in the executor, so it should fill the requirement. What do you think ? Baptiste > MP: Context propagation impossible using AsyncInvocationInterceptorFactory > --- > > Key: CXF-8303 > URL: https://issues.apache.org/jira/browse/CXF-8303 > Project: CXF > Issue Type: Bug > Components: MicroProfile >Reporter: Baptiste AIGLIN >Assignee: Andriy Redko >Priority: Major > Attachments: cxf-context-reproducer.zip > > > Hello! > We are deeply working using the Microprofile rest client implementation of > CXF and we have trouble with the context propagation between threads. > We have implemented AsyncInvocationInterceptorFactory and use it to propagate > threadLocal context on the receiving thread after an asynchronous call, but I > found some problem due to this: > * Call is performed from the main thread > * Response is handled in the CXF work queue, that execute the interceptor > chain and propagate the thread local context correctly > * During the chain execution the response entity is set to notify the future > but it then execute in the executor thread (By default ForkJoinPool) > So the fact that the future is returned using the *Async method of the > CompletableFuture makes the next stage to execute in the executor > (ForkJoinPool) thread where the context was not propagated. > > I am not saying this is simple since it is not, but could it be possible to > return the future itself rather than using the custom executor > (ForkJoinPool), and instead use the custom executor the same way it is used > for JAX-WS where I think it is set as Executor in the exchange and later > retrieve by the conduit to perform the response execution ? > Also we noticed due to this that as soon as the response is notified, the > full interceptor chain is not yet executed and continue to execute in the > workqueue thread while the next stage is starting to execute in the > ForkJoinPool thread. > I hope I was clear enough. I add a reproducer with the dummy solution I could > come up with to see what I am asking is at least fixing the problem. Also I > know a fix is already ongoing here > https://issues.apache.org/jira/browse/CXF-8242 but is using > thenApplyAsync(res -> (T)res[0], executor), so should not fix the problem. > Thanks a lot -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CXF-8299) MP Rest Client 2.0: Handle different Query Parameter types
[
https://issues.apache.org/jira/browse/CXF-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy McCright resolved CXF-8299.
Resolution: Fixed
> MP Rest Client 2.0: Handle different Query Parameter types
> --
>
> Key: CXF-8299
> URL: https://issues.apache.org/jira/browse/CXF-8299
> Project: CXF
> Issue Type: Sub-task
> Components: MicroProfile
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.4.0
>
>
> See MP Rest Client Issue [217|[MP Rest Client overlooks Collection handling
> in params|https://github.com/eclipse/microprofile-rest-client/issues/217]]
>
> Users would like to configure how the MP Rest Client will format query
> parameters when multiple values are specified for the same parameter key.
> Styles include the normal/expanded format like
> {color:#505f79}foo=v1&foo=v2&foo-v3{color} vs comma-separated like
> {color:#505f79}foo=v1,v2,v3{color} vs array syntax (which is heavily used in
> PHP servers) like {color:#505f79}foo[]=v1&foo[]=v2&foo[]=v3{color}.
>
> CXF already covers the first two cases. This issue should add array syntax
> and should update the MP Rest Client implementation to allow users to select
> between the different styles.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CXF-8304) MP Rest Client 2.0: Use CDI-managed providers
[ https://issues.apache.org/jira/browse/CXF-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy McCright resolved CXF-8304. Resolution: Fixed > MP Rest Client 2.0: Use CDI-managed providers > - > > Key: CXF-8304 > URL: https://issues.apache.org/jira/browse/CXF-8304 > Project: CXF > Issue Type: Sub-task > Components: MicroProfile >Reporter: Andy McCright >Assignee: Andy McCright >Priority: Major > Fix For: 3.4.0 > > > In MP Rest Client [issue > 256|https://github.com/eclipse/microprofile-rest-client/issues/256] > (implemented by [PR > 277|https://github.com/eclipse/microprofile-rest-client/pull/277], > implementations are required to check (1) if CDI exists in the runtime and > (2) if CDI is managing an instance of the provider class specified by the > client interface - and if so, then use the CDI-managed provider instead of > creating one using newInstance(). This applies for cases where the provider > _class_ is registered, not a pre-created _instance_ of the provider. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CXF-8262) Implement MicroProfile Rest Client 2.0
[ https://issues.apache.org/jira/browse/CXF-8262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy McCright resolved CXF-8262. Resolution: Fixed > Implement MicroProfile Rest Client 2.0 > -- > > Key: CXF-8262 > URL: https://issues.apache.org/jira/browse/CXF-8262 > Project: CXF > Issue Type: New Feature > Components: MicroProfile >Reporter: Andy McCright >Assignee: Andy McCright >Priority: Major > Fix For: 3.4.0 > > > The MicroProfile Rest Client 2.0 API is scheduled for release in June 2020. > The milestone plan for the 2.0 release is available here: > [https://github.com/eclipse/microprofile-rest-client/milestone/6] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CXF-8262) Implement MicroProfile Rest Client 2.0
[ https://issues.apache.org/jira/browse/CXF-8262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138971#comment-17138971 ] Andy McCright commented on CXF-8262: [~coheigea] - Sorry for not responding earlier - this is effectively done now, but due to issues with MicroProfile Working Group, they cannot release a GA version of the MP Rest Client APIs until August at the earliest. The implementation in CXF is done though (using the latest release candidate of the APIs) and I don't anticipate any changes to the API between RC2 and GA, so I'll mark this as resolved. Thanks! > Implement MicroProfile Rest Client 2.0 > -- > > Key: CXF-8262 > URL: https://issues.apache.org/jira/browse/CXF-8262 > Project: CXF > Issue Type: New Feature > Components: MicroProfile >Reporter: Andy McCright >Assignee: Andy McCright >Priority: Major > Fix For: 3.4.0 > > > The MicroProfile Rest Client 2.0 API is scheduled for release in June 2020. > The milestone plan for the 2.0 release is available here: > [https://github.com/eclipse/microprofile-rest-client/milestone/6] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
