-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Modifying Contract to support passing all parameters to encoders #1448 #1459
Conversation
I noticed CircleCI build failed. However, the error is not related to my changes. Here is the error:
When building from my laptop I skip that license header check by adding What should be done to avoid this build error in CircleCI? |
Run |
@velo build passed. |
Sweet, I gave it a very initial pass. I see no tests for it, could you please include some?! |
cbdb8db
to
4f2c1ff
Compare
@velo added tests. Builds passed. Thanks. |
@velo hello. Checking if you had a chance to review the PR. Thanks. |
thanks Fabio, I downloaded a copy of your changes here, and I'm tinkering around, trying to avoid this boolean, in an attempt to create a more generalized solution. Hopefully I will have an answer over the weekend |
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.
Meets the need and fits as a minimum viable release. I'm going to approve it, pending additional comments from @velo
Thanks. Let me know if you have any question, or need any change. |
I still feel this should be a contract-only change. Contract holds the magic on how to prepare payloads for encoders, so, it alone should be able to "translate" method arguments into an Object[] or Map<> or even a different object assembled method arguments. Just haven't figure HOW yet. I just don't wanna introduce a "fabio" specific change now, to only figure that we should have done something else later. |
Sorry, I thought this is the Contact change we have been discussing. Isn't it? As opposed to changing the Encoder API.
But that is exactly what this solution does, it delivers all method arguments into a
I hear you, no one wants specific solutions, including myself, trust me, otherwise the project becomes unmaintainable and nobody wants their projects to rely on unmainatable libraries. I have maintained 3 different open source projects, so I know what you are talking about. I am just not sure that is the case here, as (please correct me if I am wrong) the PR meets what has been asked in the discussion in this thread, including the points in your last comment. Anyways, please let me know if you have any other idea, or if there is anything else I can do to help, I would be glad to change anything and retest. Thanks. |
My concern, is this boolean is behaving more like an "body no op contract", and then we need to check the boolean everywhere to ensure correct behavior. Let's say we have a client like this:
Feign behave in very distinct ways with I was not able to find a different solution for your problem over the weekend, and I won't have the time to get a different approach. Let's compromise. Instead of having I don't exactly have a name suggestion for that class, maybe something like If you happy to proceed with that, I would merge and release feign 11.5 today. |
@velo Thank you very much. I will implement the changes you mentioned now. |
* | ||
* @author fabiocarvalho777@gmail.com | ||
*/ | ||
public abstract class AlwaysEncodeBodyContract extends DeclarativeContract { |
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.
Since the purpose of this class is to allow the body always to be defined by the encoder, there was no need to add alwaysEncodeBody
field here.
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.
Notice this class extends DeclarativeContract
, instead of BaseContract
. That is necessary to take advantage of the annotations processors, which is required for extensions of AlwaysEncodeBodyContract
.
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.
makes sense.
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.
Looking good
@@ -111,7 +84,9 @@ protected MethodMetadata parseAndValidateMetadata(Class<?> targetType, Method me | |||
data.method(method); | |||
data.returnType(Types.resolve(targetType, targetType, method.getGenericReturnType())); | |||
data.configKey(Feign.configKey(targetType, method)); | |||
data.alwaysEncodeBody(this.alwaysEncodeBody); | |||
if (AlwaysEncodeBodyContract.class.isAssignableFrom(this.getClass())) { |
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.
can't you override this method on the subclass?
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.
na, I don't think it's possible.
ok, nvm
@@ -84,6 +84,9 @@ protected MethodMetadata parseAndValidateMetadata(Class<?> targetType, Method me | |||
data.method(method); | |||
data.returnType(Types.resolve(targetType, targetType, method.getGenericReturnType())); | |||
data.configKey(Feign.configKey(targetType, method)); | |||
if (AlwaysEncodeBodyContract.class.isAssignableFrom(this.getClass())) { |
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.
This setting is necessary here to avoid having to override this whole method (a copy plus this setting) under AlwaysEncodeBodyContract
.
All good, sorry for holding this for so long. FWIW, the way I would love to see this done (as in the future) is something like this:
The main advantage of this Prefer a Map instead, sure:
Do you have your own object, not a problem
HOW you may ask?! No idea, I just have a dream! |
This PR addresses issue #1448
@velo @kdavisk6 please just let me know if you have any requests for changes, or if this PR should be opened against a different branch and I will do it. Thank you very much.