Syed Mudassir Ahmed created CXF-8375:
----------------------------------------
Summary: Access to httpprocessor field of HttpAsyncClientBuilder
in AsyncHTTPConduitFactory
Key: CXF-8375
URL: https://issues.apache.org/jira/browse/CXF-8375
Project: CXF
Issue Type: New Feature
Components: Transports
Affects Versions: 3.4.1
Reporter: Syed Mudassir Ahmed
Fix For: 3.4.2
In CXF versions 2.7.18, we clearly had access to httpProcessor as per this
commit
[https://github.com/apache/cxf/commit/a18be4fac03d3886317b0201123e9917d1a33e60#diff-f5349d24a3d1a3bced2aa168ce24d586461fe743d2e0b72f0fafcfedb9a99234L132.]
I don't know why access to that httpProcessor is revoked in the subsequent
versions of CXF.
We were facing a problem. We were talking to a webservice. The webservice
returns a redirect 3XX response mentioning the new host to talk to. And that
host actually contains port as well such as "newserver.com:80".
And while handling the redirect, CXF was putting the target host in the request
as "newserver:80" instead of just "newserver". This was failing and we were
not able to fetch the results.
The fix was to add a custom HTTP request interceptor in httpProcessor. This
interceptor stays on top of all the other interceptors. And it simply chops
the port and add the target host as just "newserver".
It worked well in CXF version 2.7.18. The moment we migrated to CXF 3.x (due
to moving to JDK11) then our app starting giving compilation error. Because in
3.x version, access to that httpProcessor is revoked.
I would suggest to regain the access to that field since it was already like
that before. I know mine could be a rare requirement but it was easy for to
add an interceptor to httpProcessor earlier.
Right now, we have to create a custom factory and get the things done. They
are not that straight-forward. If we had access to httpProcessor then no need
to create any custom factory. We can simply add our interceptors directly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
