Add Dependency Detection and Fallback Logic for OkHttp
Check Ahead
-
[x] I have searched the issues of this repository and believe that this is not a duplicate.
-
[ ] I am willing to try to implement this feature myself.
Why you need it?
To make the transition from HttpClient4 to OkHttp smoother, we need to implement dependency detection and fallback logic
- If OkHttp is available → use OkHttp implementation
- If OkHttp is not available → fallback to HttpClient4
- When falling back, log a warning message:
How it could be?
- Detect whether OkHttp is available on the classpath
- Use OkHttp implementation if available
- If not available, fallback to OkHttp and log a warning message
Other related information
You can start this task once the PR below has been merged.
- https://github.com/apache/incubator-seata/pull/7492
PLS assign it to me
@YvCeung
Since the dependency has been changed from HttpClient5 to OkHttp, this issue should be updated accordingly.
I plan to update the issue later this week.
In the meantime, it would be great to take a look at the merged PR and start thinking about how to approach the implementation.
- https://github.com/apache/incubator-seata/pull/7492
@YvCeung
As the first step for this PR, I recommend identifying the scenarios where OkHttp cannot be used.
It would be helpful to investigate various conditions, such as JDK versions and supported HTTP versions.
After that, consider whether HttpClient4 can be used properly in those cases.
If this is going to take some time, I’d recommend working on #7560 first.
As the first step for this PR, I recommend identifying the scenarios where
OkHttpcannot be used. It would be helpful to investigate various conditions, such asJDKversions and supportedHTTPversions.After that, consider whether
HttpClient4can be used properly in those cases.
Should I wait until issue is #7544 completed before starting my task?
Should I wait until issue is #7544 completed before starting my task?
Nope, You don't have to wait :)