Skip to content
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

Configure JSON serializer #413

Closed
wants to merge 3 commits into from
Closed

Conversation

sungam3r
Copy link
Contributor

@sungam3r sungam3r commented Jan 3, 2025

Small change to allow configuration of used JSON serializer, no breaking changes. I know about #43 and #158 but it seems work is stalled. I suggest to do a small step forward on existing serializer to allow configure it. I was faced with the fact that I can’t configure the serialization of some request metadata as it is necessary.

@marcin-krystianc
Copy link
Contributor

Hi @sungam3r,

can you give more details about your use case? Ideally, we want to avoid adding a public method with an argument type from Newtonsoft.Json (I'm asking, because it makes it harder to replace Netwtonsoft.Json with System.Text.Json in the future).

@sungam3r
Copy link
Contributor Author

sungam3r commented Jan 7, 2025

I understand your reasoning about public method referencing nsj, but migration to stj will be a breaking change anyway - other lib dependency, other attributes, other converters, etc. Besides, PR with this migration looks abandoned and honestly I do not feel that this migration happens in the near future.

Now about my case. I'm not going to change some default settings here but rather want to revert them to be default ones because some component in my process environment hijack default serializer settings globally and so it badly influences on serialization performed by consul client. I just want to be able to specify serialization settings particularly for consul client to make it stable and independent from global settings.

@sungam3r
Copy link
Contributor Author

@marcin-krystianc Do you need additional information from me?

@marcin-krystianc
Copy link
Contributor

@marcin-krystianc Do you need additional information from me?

Hi sungam3r, I'm sorry I was occupied last week. I'm just now starting to work on this issue.

@marcin-krystianc
Copy link
Contributor

Now about my case. I'm not going to change some default settings here but rather want to revert them to be default ones because some component in my process environment hijack default serializer settings globally and so it badly influences on serialization performed by consul client. I just want to be able to specify serialization settings particularly for consul client to make it stable and independent from global settings.

Could you share a code snipped that will let me reproduce the issue?

@sungam3r
Copy link
Contributor Author

I have no snippet but I'm sure you may reproduce behavior simply adding something like this

JsonConvert.DefaultSettings = () => new JsonSerializerSettings
{
    Formatting = some_unusual_value,
    TypeNameHandling = some_unusual_value,
    ContractResolver = new some_unusual_contract_resolver_printing_awkward_things
};

in the beginning of test initialization.

@sungam3r
Copy link
Contributor Author

Or I can push commit trying to do the same myself. Ok?

@marcin-krystianc
Copy link
Contributor

I have no snippet but I'm sure you may reproduce behavior simply adding something like this

JsonConvert.DefaultSettings = () => new JsonSerializerSettings
{
    Formatting = some_unusual_value,
    TypeNameHandling = some_unusual_value,
    ContractResolver = new some_unusual_contract_resolver_printing_awkward_things
};

in the beginning of test initialization.

Thanks, indeed it is very easy to break our library by overriding the default serializer settings.
I am still not convinced that exposing Newtonsoft even more in the public API is the right thing to do. Shouldn't we try to make the library independent from overriding the DefaultSettings? That wouldn't change the public API, but it would help with your problem.

@marcin-krystianc
Copy link
Contributor

@sungam3r
I opened an alternative PR. It fixes the issue but doesn't require API changes -> #417

@sungam3r
Copy link
Contributor Author

I'm fine with such alternative. It suits my needs. Thanks.

@sungam3r
Copy link
Contributor Author

Replaced by #417 .

@sungam3r sungam3r closed this Jan 21, 2025
@sungam3r sungam3r deleted the configure branch January 21, 2025 20:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants