potential support for customize gson #704
Conversation
Customers can just bind to string and do their own deserialization, but I feel that this breaks the POJO scenario. When binding to a POJO, we should be able to handle that properly or allow for customers to customize gson as suggested here. This will avoid exceptions when deserializing something like I think we should avoid guiding customers to use string binding when we can't deserialize their payload because of something like a date format, that's more an issue with us than with their code. |
@kaibocai The PR to fix the default DateTime for the timer info has been merged and should be released within the next month or so. However, I would still recommend this support for custom gson builder to avoid issues like this with other types and to provide user's more flexibility. |
yes, we definitely need to provide flexibility to customize serializing and deserializing. |
|
|
||
| public static void setGsonInstance(Gson instance) { | ||
| if (gsonInstance == null) { | ||
| synchronized (utilLock) { |
There was a problem hiding this comment.
No need to add sync block here, it's already thread safe with the sync block at
|
Issues - #720 |
Issue describing the changes in this PR
A primitive implementation for support customizing gson instance used in java worker.
Issues opened on hard code gson instance are many: #682, #424, #419, Azure/azure-functions-host#7391, etc.
So maybe it's good to add flexibility supporting customer customize their gson instance.
Another solution would be work with Azure java sdk team on moving out of gson with better choice.
Board link: https://msazure.visualstudio.com/Antares/_boards/board/t/Functions%20Java/Backlog%20items/?workitem=17209424
SPI requirement: Azure/azure-functions-java-additions#20
This feature may not be needed at all, as most customer can using plan String and customize their gson instance inside their function to deserialize.
Pull request checklist
release_notes.mdAdditional information
Additional PR information