Aresxue commented on PR #13066: URL: https://github.com/apache/dubbo/pull/13066#issuecomment-1980283430
> > > > > How can the user specify it in **one invocation** > > > > > > > > > > > > set attachment in RpcContext > > > > ```java > > > > RpcContext.getClientAttachment().setObjectAttachment(GENERIC_WITH_CLZ_KEY, "true"); > > > > ``` > > > > > > > > > This is a little wired. I wonder why we should support this future? Is there any scenarios? > > > > > > Because we don’t want to rely solely on the provider’s configuration to control whether to return the class field. Different consumers have different expectations for the class field. Our open platform will return the results to the third-party manufacturers. They want a result that does not contain class, but for In other scenarios, for example, I am doing dubbo traffic playback, then I want to get the class field when making a generalized call, because I need to restore the original untyped object to a java type object. In addition, we are based on dubbo Frameworks that implement extension point mechanisms also rely on classes to restore type information. > > How about add a Filter to customize the response object? This would be more flexible. Sorry, I don't understand what filter has to do with this. If you mean to remove the redundant class field, consumers can traverse it in their own project code. For now, if the provider is configured with -Dgeneric.include.class=false, the consumer will not be able to obtain the class field anyway. Then I will not be able to restore the java object in some scenarios. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
