You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our dependency on Jersey causes conflicts in downstream applications that rely on another, incompatible version of Jersey. Initial analysis indicates that we won’t be able to solve this with clever dependency isolation. This task is to swap in another HTTP client to address the customer dependency incompatibilities.
The priority for this update is for the 3.x branch. #738 tracks this for the 4.x branch.
Whichever library we chose, it must be possible for a client to use any different version of that same library in their application.
There should be no external interface changes as a result of the swap. In other words, an application should behave the same as it did before without modifying code. Our message to existing users should be that this change is the only change represented in this release and their application should behave just as it did before.
There should not be significant performance or resource usage degradations. We must document performance differences.
The security vulnerability surface area must not be significantly different than what we know about Jersey today. We should document a process for tracking and addressing new vulnerabilities.
In the interest of reducing complexity and simplifying upgrade, we should aspire to making this the only change in whichever release in which this gets rolled out.
Have we exhausted all of our “clever dependency isolation“ tricks?
We have advanced support for configuring the existing HTTP client. What will happen to that code? Document this as a known incompatibility? What are the knobs and levers that the new HTTP library affords for configuration?
The text was updated successfully, but these errors were encountered:
Our dependency on Jersey causes conflicts in downstream applications that rely on another, incompatible version of Jersey. Initial analysis indicates that we won’t be able to solve this with clever dependency isolation. This task is to swap in another HTTP client to address the customer dependency incompatibilities.
The priority for this update is for the
3.x
branch. #738 tracks this for the4.x
branch.In the interest of reducing complexity and simplifying upgrade, we should aspire to making this the only change in whichever release in which this gets rolled out.
Related Issues
Open Issues
The text was updated successfully, but these errors were encountered: