-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade Feign #1337
Upgrade Feign #1337
Conversation
Generate changelog in
|
Feign removed the ability to escape expansion of variables by using |
...c/test/java/com/palantir/conjure/java/client/jaxrs/JaxRsClientJava8OptionalHandlingTest.java
Show resolved
Hide resolved
Looks awesome @pkoenig10 thank you for chasing this down. For the hr-path-template thing, perhaps something like Also I think I remember something to do with possible classpath conflicts - both |
Yeah, I just wanted to make sure it was acceptable to change the format. I think this is only used to generate span names, so it should be fine to just use another delimiter.
Yeah this is definitely a risk. But it's probably something we will need to address eventually. Do we have any tooling to handle these types of upgrades? Maybe we could update the conjure upgrade excavator to somehow handle this? |
@@ -8,26 +8,26 @@ dependencies { | |||
api "com.google.code.findbugs:jsr305" | |||
api "javax.ws.rs:javax.ws.rs-api" | |||
// TODO(dsanduleac): Should be implementation, but can't because we expose feign.TextDelegateEncoder | |||
api "com.netflix.feign:feign-core" | |||
api "io.github.openfeign:feign-core" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pkoenig10 I think the TODO above might be out of date... afaik the reason this has to be api is because people may want to catch a RetryableException
So I think for most consumers of c-j-r the dependency problems should be fine and the PR will clearly show all the I think before rolling this out I'd like to figure out the right gradle concept to make sure these don't fight (might be capabilities or it might be plain old dependency substitution). e.g. allprojects {
dependencies {
modules {
module('com.netflix.feign:feign-core') {
replacedBy('io.github.openfeign:feign-core', 'Feign is now published under new maven coordinates')
}
}
}
} I think Gradle will now consider the two modules as a single module in dependency resolution and will never include both, but there's still a danger of NoSuchMethodErrors. |
Please can we just shade the Feign we use? This stuff ends up really hard to upgrade, we shouldn't let diamond dependencies hurt us. |
Yeah this seems like the best approach. We would also have to keep the old Feign dependency to avoid runtime errors if users are transitively depending on it, right? |
If we rev the major version we can avoid keeping the old feign dependency, it would cause a potential compile break, not a runtime break. |
I was under the impression that GCV does not have a concept of major versions. So GCV could resolve to a 4.x version without the feign dependency even though you're dependency was compiled with a 3.x version and relies on the transitive feign dependency being present. |
Also, shading feign will be a breaking change because we have users that catch Granted, they probably should just be catching |
This PR has been automatically marked as stale because it has not been touched in the last 14 days. If you'd like to keep it open, please leave a comment or add the 'long-lived' label, otherwise it'll be closed in 7 days. |
@j-baker @carterkozak any thoughts on how we could safely shade feign? |
This PR has been automatically marked as stale because it has not been touched in the last 14 days. If you'd like to keep it open, please leave a comment or add the 'long-lived' label, otherwise it'll be closed in 7 days. |
Fixes #790
Fixes #1330
Fixes #1331
Possible downsides?
This upgrade causes a regression in the handling of
optional<string>
header parameters when the value is an empty string. Before this PR these parameters would be serialized as a present header with an empty string value. After this PR these parameters will be omitted from the request and the server will deserialize the parameter as an absent optional value.However, this PR does fix the incorrect handling of absent optional values (all types of optional values are affected by this bug). This tradeoff seems like a net positive, see #790 (comment). We're correcting the behavior of absent optional values of any type at the cost of empty string optional values.