Aws-lambda-dotnet: Amazon.Lambda.Serialization.SystemTextJson.LambdaJsonSerializerは、Amazon.Lambda.Serialization.Json.JsonSerializerとは異なるプロパティケーシングを使用します

作成日 2020年04月15日 · 43コメント · ソース: aws/aws-lambda-dotnet

デフォルトのケーシングの動作がAmazon.Lambda.Serialization.Json.JsonSerializerとAmazon.Lambda.Serialization.SystemTextJson.LambdaJsonSerializer間で変更されたようです。

違いをテストするためのサンプルコードを次に示します。

// create an instance to serialize
var record = new Record {
    Foo = "Hello world!"
};

// show serialization with original Lambda serializer based on Newtonsoft.Json
var oldSerializer = SerializeWith(record, new Amazon.Lambda.Serialization.Json.JsonSerializer());
Console.WriteLine($"Amazon.Lambda.Serialization.Json.JsonSerializer: {oldSerializer}");

// show serialization with new Lambda serializer based on System.Text.Json
var newSerializer = SerializeWith(record, new Amazon.Lambda.Serialization.SystemTextJson.LambdaJsonSerializer());
Console.WriteLine($"Amazon.Lambda.Serialization.SystemTextJson.LambdaJsonSerializer: {newSerializer}");

// show serialization with System.Json.Text
var jsonTextSerializer = System.Text.Json.JsonSerializer.Serialize<Record>(record);
Console.WriteLine($"System.Text.Json.JsonSerializer: {jsonTextSerializer}");

// local functions
string SerializeWith<T>(T value, Amazon.Lambda.Core.ILambdaSerializer serializer) {
    using var buffer = new MemoryStream();
    serializer.Serialize<T>(value, buffer);;
    return System.Text.Encoding.UTF8.GetString(buffer.ToArray());
}

上記のコードは、次の出力を生成します。

Amazon.Lambda.Serialization.Json.JsonSerializer: {"Foo":"Hello world!"}
Amazon.Lambda.Serialization.SystemTextJson.LambdaJsonSerializer: {"foo":"Hello world!"}
System.Text.Json.JsonSerializer: {"Foo":"Hello world!"}

bug

ソース

bjorg

最も参考になるコメント

この問題を話題に保つことは可能ですか？

Kralizek 2020年04月24日

👍3

全てのコメント43件

2つのライブラリ間でケーシングを切り替えるべきではないことに同意しました。テストは主にAWSイベントに焦点を合わせているため、カスタムリクエストとレスポンスのテストが不足していると思います。

これが出荷されたので、デフォルトの動作を変更することは実際には実行不可能です。私の提案は、使用するケーシングを宣言できるように、ケーシングスタイルの列挙型を取り込む新しいコンストラクターを追加することです。次に、新しいコンストラクターを使用するようにテンプレートを更新できます。その回避策についてどう思いますか？

normj 2020年04月15日

👎1

ここでのアイデアが何だったのかわかりません。依存関係にあるかもしれない人々を壊したくないと私は理解しています。 AWSがJSONフィールドの命名に一貫性があると信じていたのは間違いだったようです（つまり、 AWSNamingPolicy ）。そうではありません。 CloudFormationなどの一部のサービスはPascalケースを使用します。
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/crpg-ref-responses.html

ケーシングを自動的に変更し、デフォルトのSystem.Text.Json動作を尊重しないことは、致命的な欠陥です、IMHO。たぶん、 Amazon.Lambda.Serialization.SystemTextJson.LambdaJsonSerializerV2をリリースして、古いものを氷上に置くことを検討してください。

bjorg 2020年04月15日

👍1

明確にするために、これがどのように機能するかよくわからないので、アセンブリ属性宣言は逆シリアル化にのみ使用されますよね？

[assembly: LambdaSerializer(typeof(Amazon.Lambda.SystemTextJson.LambdaJsonSerializer))]

ただし、このハンドラー署名を使用する場合でも必要ですか？

Task<Stream> FunctionHandlerAsync(Stream stream, ILambdaContext context)

アセンブリまたはエントリポイントメソッドにLambdaSerializerAttribute宣言がない場合はどうなりますか？

bjorg 2020年04月15日

@normjオプションは、属性を追加してjsonプロパティに明示的に名前を付けることで、

3GDXC 2020年04月16日

👍1

私はその提案に同意します-それらを追加するのは退屈な一回限りの作業ですが、そうすればそれらは常に正しいです。

martincostello 2020年04月16日

@normj IMHOこれは実装の問題であり、これは

3GDXC 2020年04月16日

@ 3GDXC実装のバグであることに同意します。解決策を考えているだけです。現在、パッケージにはLambdaJsonSerializerという1つのシリアライザーがあります。 LambdaJsonSerializerから拡張するPascalCaseLambdaJsonSerializerとCamelCaseLambdaJsonSerializerシリアライザーを追加するとどうなりますか。テンプレートを変更してPascalCaseLambdaJsonSerializerを使用し、既存の動作を維持することができます。これは、ソートLambdaJsonSerializerV2を持つの@bjorg提案のより明示的なバージョンです。

normj 2020年04月16日

@normj IMHOは、メッセージにJsonPropertyName属性を追加して、シリアライザーの構成/オプションに関係なく、結果のJsonが属性の命名に準拠するようにすることをお勧めします。

.NET 3.1サポートのリリースから数日以内に（修正を加えて）さらに重大な変更を導入することを躊躇する理由を完全に理解しています。また、 UP-FOR-GRABSの問題が

必要に応じて、言葉を言ってください。

これまでのところ素晴らしい仕事であり、awslambaと.netコアサポートが成長するのを見るのが大好きです

3GDXC 2020年04月16日

@ 3GDXC大文字と小文字は、.NETオブジェクトからJSON文字列に移動する必要がある戻りオブジェクトにのみ影響することにます。例を次に示します： //github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.APIGatewayEvents/APIGatewayProxyResponse。 cs＃L18

問題は、他の人が作成する応答オブジェクトで、JsonPropertyName属性を使用するかどうかを制御できません。

normj 2020年04月16日

@normj良い点; 助言かもしれも常にJsonPropertyNameがあなたの特性および/またはデータコントラクト（ベストプラクティス）の明示的なネーミングを強制するために属性を使用含める必要があります

3GDXC 2020年04月16日

@normjの代わりに、JsonSerializerOptionsをLambdaSerializerOptionsクラスに抽象化し、属性のコンストラクターパラメーターとしてオプションを追加して、開発者がアセンブリ/メソッドレベルでオーバーライドできるカスタムオプションをシリアライザーが持つことができるようにすることもできます。

3GDXC 2020年04月16日

より多くの害を広めるのではなく、リグレッションとしてフラグを立て、今すぐ重大な変更として修正するのはどうですか？ System.Text.Jsonに基づくLambdaJsonSerializer 、プロパティのシリアル化方法のデフォルトの動作を尊重しないため、これを_harm_と呼びます。もちろん、 [JsonPropertyName]すると修正されますが、望ましくない動作に対抗するために全員に何かを要求するのは手間がかかるようです。

標準のシリアライザーとしてLambdaJsonSerializerを採用するとき、何人の人が_？！？！？_の瞬間としてこれに遭遇し続けるでしょうか？

bjorg 2020年04月16日

こんにちは。ラムダタスクを.Net3.1 +新しいシリアライザーに切り替えた後、ステップ関数でこの問題が発生しています。出力がキャメルケースになっているため、大混乱を引き起こしています。次のステートマシンシェイプは、Amazon States Languageを使用して新しいJSONを評価しようとし、StepFunction例外をスローします。

今のところ、厄介な回避策があります。環境変数にLAMBDA_NET_SERIALIZER_DEBUG=trueを設定することにより、 _.optionsがシリアライザーに設定されることはなく、ケースはそのまま返されます。それによって、追加のJSON以外の影響がCloudwatchログに出力されるかどうかはわかりません。
https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.Serialization.SystemTextJson/LambdaJsonSerializer.cs#L69 -L90

IMO、モデルは多くのnugetライブラリに埋め込まれているため、すべてのモデルを[JsonPropertyName]装飾で装飾するのは面倒です。理想的には、デフォルトの動作を以前と同じように元のPascalCasingに戻したいのですが、Step Functionプロジェクトで呼び出されたときに、ラムダで明示的なPascalCaseLambdaJsonSerializerしても問題ありません。

ありがとう！

panodk 2020年04月16日

👍3

厄介な回避策はバグだと確信しています。

アップストリームアセンブリによって定義されたデータ構造の良い点。

bjorg 2020年04月16日

[JsonPropertyName]属性がないと、他のものにどのような副作用があるかわかりませんが、JSONシリアライザーをカスタマイズできるLambdaJsonSerializerコンストラクターを使用すると、次の方法でデフォルトのPascalCaseの動作に戻すことができます。 JsonSerializerOptions.PropertyNamingPolicyをnullます。

martincostello 2020年04月16日

👍1

このディスカッションに関連しているため、問題＃628にリンクしています。

bjorg 2020年04月18日

これは関係があると思います。

APIGatewayProxyRequest.csを見ると、 [JsonPropertyName]アノテーションがないことに気づきました。これが機能する唯一の理由は、a） LambdaJsonSerializerデフォルトで大文字と小文字を区別しない逆シリアル化になり、b） LambdaJsonSerializerがシリアル化にキャメルケースを使用するためです。

これにより、さまざまなヘルパーアセンブリのすべての要求/応答クラスに注釈を付けるのに多くの時間を節約できたことがわかりますが、ヘルパーアセンブリを使用する場合は、関数でLambdaJsonSerializerを使用する必要があることを意味します。

後から考えると、関数クラス自体ではなく、関数ハンドラーによって使用されるPOCOクラスに[LambdaSerializer(typeof(Amazon.Lambda.Serialization.Json.JsonSerializer))]アノテーションを付ける方が理にかなっていますか？最終的に、関数は要求/応答クラスに一致するシリアライザーを使用する必要があるようです。

bjorg 2020年04月18日

@bjorg IMO POCOは、使用されるシリアル化に関する属性メタデータを持つのに間違った場所です。 POCOは、そのドメイン、つまりモデル検証属性とプロパティタイプ/名前付けのみに関係する必要があります。シリアル化では、これらのモデル注釈を尊重/使用する必要があります。

IMHO LambdaSerializer属性は、シリアル化のタイプを受け入れるように変更する必要があります。オプションのシリアル化オプションを備えたAmazon.Lambda.Serialization.Json.JsonSerializer。オプションが指定されていない場合、デフォルトで互換性のある設定が使用されます。

grahamehorner 2020年04月18日

ただし、POCOには、正しいシリアライザー属性（Newtonsoftの場合は[JsonProperty] [JsonPropertyName] 、System.Text.Jsonの場合は

bjorg 2020年04月18日

[DataMember]はNewtonsoft.JsonとSystem.Text.Json両方でサポートされるようです。ただし、後者の場合は.NET5までではありません。 :(
https://github.com/dotnet/runtime/issues/29975

それまでの間、解決策は、すべてのPOCOに[DataMember]と[JsonPropertyName]注釈を付けることです。どちらの属性も.NETCore 3.1で定義されているため、追加の外部依存関係は必要ありません。

これにより、少なくともプロパティ名について、すべてのクラスで一貫したシリアル化/逆シリアル化が保証されませんか？コンバーターは、 ILambdaSerialize実装によって登録される必要があります。

bjorg 2020年04月18日

そこにリンクされている問題はクローズされています。そのスレッドを読んだスキムからの私の理解は、彼らがそれをサポートするつもりはないということです： https ：

martincostello 2020年04月18日

うん。読み間違えました。 5.0のリンクを見て、間違った結論に飛びつきました。

bjorg 2020年04月18日

この問題に対処するために、PRhttps ：//github.com/aws/aws-lambda-dotnet/pull/636を公開しました。フィードバックをいただければ幸いですが、PRのリンクからプレビュービルドをダウンロードして、変更が機能することを確認してください。

normj 2020年04月19日

😄1

まず、これに非常に迅速に取り組んでくれてありがとう。土曜日を台無しにしてすみません。

一見良さそうです。現在、すべてのNewtonsoft.Json参照を削除するプロセスを進めていますが、残念ながら、修正を確認できる状態ではありません。今のところ、問題のあるシリアライザークラスをコピーして、問題のあるステートメントを削除しました。うまくいけば、明日のEODまでに、開発ブランチでこの変更をテストできます。

最初に頭に浮かぶのは、注釈が欠落している可能性があることです。 [DataMember]を使用せず、代わりに暗黙のキャメルケースに依存した応答データ構造はありましたか？

bjorg 2020年04月19日

@bjorg心配ありません。 1週間の会議、ドキュメントの作成、学校での子供たちの支援の後、静かな時間を過ごし、土曜日のコーディングを行うことは非常に快適でした。

Newtonsoftシリアライザーで[DataMember]アノテーションが欠落する可能性がありました。既知のタイプについてはテストがあるので、私はそれについてあまり心配していません。この場合、私のギャップにはカスタム応答のテストがありませんでした。

normj 2020年04月19日

-rc1をリリースすることは可能でしょうか？別の方法であるAFAIKは、適切なコンパイル定数を有効にして_.csproj_ファイルをハックする方法です。別の方法はありますか？

bjorg 2020年04月20日

@bjorg PRには、ビルド済みのNuGetパッケージを含むzipファイルへのリンクがあります。ローカルのNuGetソースをセットアップして、そこにパッケージを配置できますか？

normj 2020年04月20日

今日、何か新しいことを学びました。ローカルフィードを取得する方法です。 .NET Coreでは非常に簡単であることが判明しました（ SOの記事を参照）。

私の最も適切なフィードバックは、 _optionsを保護された/パブリックのOptionsプロパティとして公開し、派生クラスでも使用できるようにすることです。

そうでなければ、私の側からのこの新しいコードですべてが素晴らしいです。 THX！

bjorg 2020年04月20日

@normjは、更新されたnugetパッケージがあるかどうか/いつ更新されるかを知らせてくれます。もう一度テストを実行してください。

bjorg 2020年04月22日

https://github.com/aws/aws-lambda-dotnet/issues/544#issuecomment -567780775

^キャメルケースを使用しないと、API Gatewayが破損するためですか？

ラムダがALB上にある場合、Cos Pascalは正常に機能しますが、API Gatewayでは機能しないため、この不整合は混乱を招きます。 system.textに移行する前は、これはどのように機能しましたか？

phillip-haydon 2020年04月23日

これは重大な変更です。インターフェイスは準拠していません。統合テストやリリース候補のコミュニティレビューが不足しているため、このインターフェイス分離の原則の違反はすり抜けました。これが未解決のままでいる時間が長ければ長いほど、AWSクライアントにコストと工数の浪費が発生し、AWSの評判に影響を及ぼします。

このリリースを壊れたものとしてマークするように移動し、修正が合意されるまで、すべての開発者が3.1に移行しないようにすることをお勧めします。
さらに、問題がさらに悪化する可能性を減らすために、修正についてコミュニティで話し合い、完全にテストすることをお勧めします。

lukebrowell 2020年04月23日

👍2

@lukebrowellシリアライザーの作業は、1月に提出されたPRで公開されました。 https://github.com/aws/aws-lambda-dotnet/pull/568 PRは、カスタムLambdaランタイムで実行できるテスト用のビルド済みパッケージを添付しました。

ここではPRとともに修正について話し合っており、提案された修正に関するフィードバックを歓迎しますhttps://github.com/aws/aws-lambda-dotnet/pull/636

私はこれが重大な変更であることに同意し、それが起こるのは残念ですが、あなたが提案する重大度には同意しません。この問題は、カスタム応答を返すLambda関数にのみ影響し、すべてのLambda関数と既存のAmazon.Lambda.Serialization.Jsonが同じように機能するわけではないため、3.1Lambdaリリース全体が壊れていると言っても過言ではありません。しかし、私はフラストレーションを理解しています。このバグがすり抜けてすみません。

リリースが遅れる原因となる変更に関する重要なフィードバックがない限り、来週初めにPRの変更をプッシュしたいと思います。

normj 2020年04月23日

👍2

@bjorg PRが更新され、ビルド済みパッケージのpreview2へのリンクが追加されました。 https://normj-packages.s3.us-west-2.amazonaws.com/rework-serialization-preview2.zip

normj 2020年04月24日

👍1

@normj .netcore 3.1ランタイムを公式のラムダイメージとしてリリース/サポートするよう圧力をかけ、これを報告もフィードバックもしなかったため、これらの問題の欠落に関してコミュニティが部分的に責任を負っていることを理解しています。私見私がに関してあなたのビューがaspnetcoreラムダ関数/サービスライブラリの機能/デザインを中心に議論を開くために（フルコミュニティの関与を）私は@lukebrowellと一部に同意し、作業単位が開始されることを示唆しているコメントを@lukebrowell理解しながら、このパッケージは少し急いでTBHを感じているため、開発を進めるのに役立つマナーで特定された欠点やバグに対処することを目的としています。

grahamehorner 2020年04月24日

より強力なコミュニティを見たいです。私はawsdevelopers.slack.comにたむろしてきましたが、＃dotnetチャネルは少し静かです。 Lambda .NET Coreの人々が集まっている別の場所はありますか？

bjorg 2020年04月24日

👍1

@bjorg私は参加します;）そこに（事実上）

grahamehorner 2020年04月24日

@bjorgは招待を受けることができますか？

phillip-haydon 2020年04月24日

モデレーターから招待リンクを取得します。ここに投稿します。

bjorg 2020年04月24日

👍1

この問題を話題に保つことは可能ですか？

Kralizek 2020年04月24日

👍3

同意しました。これをトピックに留めておきましょう。 AWS slackグループに追加するための連絡方法に関するコミュニティの問題＃647を作成しました。

bjorg 2020年04月24日

はい、コミュニティコミュニケーションをより適切に設定する方法、自分のコミュニケーションをより適切に行う方法、およびより関与する方法についての提案を歓迎します。

normj 2020年04月24日

_preview2_は私には良さそうです。

bjorg 2020年04月26日

Amazon.Lambda.Serialization.SystemTextJsonのバージョン2.0.0が変更されました。メインテイクアウトは、シリアライザークラスをDefaultLambdaJsonSerializerに更新します。

また、変更について説明するセクションがあるブログ投稿を公開しました。
https://aws.amazon.com/blogs/developer/one-month-update-to-net-core-3-1-lambda/

normj 2020年04月29日

このページは役に立ちましたか？

0 / 5 - 0 評価

Aws-lambda-dotnet: Amazon.Lambda.Serialization.SystemTextJson.LambdaJsonSerializerは、Amazon.Lambda.Serialization.Json.JsonSerializerとは異なるプロパティケーシングを使用します

最も参考になるコメント

全てのコメント43件

関連する問題