問題タブ [serialization]

GWTのシリアライザーのjava.io.Serializableサポートは制限されていますが、セキュリティ上の理由から、サポートするタイプのホワイトリストがあります。私が見つけたドキュメント、たとえばこのFAQエントリには、シリアル化するタイプはすべて「シリアル化ポリシーのホワイトリストに含める必要がある」と記載されており、リストはコンパイル時に生成されますが、コンパイラがどのように決定するかについては説明されていません。ホワイトリストに載っているもの。

java.lang.String生成されたリストには、やなどの標準ライブラリの一部であるいくつかのタイプが含まれていjava.util.HashMapます。をシリアル化しようとするとエラーが発生します。これはインターフェイスjava.sql.Dateを実装していますが、ホワイトリストに含まれていません。Serializableこのタイプをリストに追加するにはどうすればよいですか？

java.awt.Image をメンバーとして保持することになっている Serializable オブジェクトがあります。シリアル化するにはどうすればよいですか？ （あまり明確ではない最初のバージョンから編集されました、申し訳ありません。）

言語に依存しないメカニズムで、ソケットまたは共有メモリを介してデータをシリアル化するメカニズムを検討しています。このデータは非常に構造化されており、エンコード/デコードの速度が非常に重要であるため、XMLの使用には消極的です。自由にライセンスされた優れたCAPIを使用することは重要ですが、理想的には、他の多くの言語をサポートする必要があります。私はグーグルのプロトコルバッファとASN.1を見てきました。私は正しい方向に進んでいますか？もっと良いものはありますか？独自のパック構造を実装するだけで、標準を探す必要はありませんか？

たとえば、HttpServlet を拡張するクラスを作成したいですか? クラスに serialVersionUID が必要であるとコンパイラが警告します。このオブジェクトが決してシリアル化されないことがわかっている場合、それらの警告を抑制するためにオブジェクトを定義するか、注釈を追加する必要がありますか?

あなたは何をしますか、なぜですか？

JSON データがいくつかありますが、すべて 1 行に収まっています。このデータをフォーマット (インデントや新しい行の挿入など) してくれ、読みやすくする Web または Windows エディターを知っている人はいますか? たとえば、再フォーマットされたドキュメントを出力するコマンドライン ツールではなく、GUI を使用して JSON を表示するものが望ましいです。

部分的に解決された問題がありました。簡単に説明すると、シリアライズが必要な複雑なオブジェクトにバインドされたグリッドがあります。オブジェクトがシリアライゼーションからビルドバックされると、グリッドのようなイベントはテーブル表示を更新しません。シリアル化を解除したら、イベントを再構築するように誰かに言われましたが、うまくいきました! しかし、グリッドを更新するイベントはまったく発生していないようです。

内部で何かが変化したことを知らせる複雑なオブジェクトからイベントを作成する必要がありました。このイベントから、このコードを追加しました:

問題は、グリッドが反転していて、ユーザーが良い感覚を持っていないことです (行が上下に移動し、停止するよりも)。

この種の反転を行わずにバインドをリセットするにはどうすればよいですか? どうすれば元の問題を解決できますか? （これにより、すべてが自動的に解決されます）。

アップデート

まったく同じ動作をする例を次に示します。

クラスを作成します。

ここで、BindingSource 呼び出し "bindingSource1" を使用してフォームを作成し、クラスをデータソースとして使用します。グリッドを作成し、グリッドを bindingsource1 にバインドします。

そのフォームでは、ロードで次のコードを使用します。

シリアル化プロセスをコメントに入れました。これがないと同じ奇妙な動作をするように見えるためです...今すぐアプリケーションを起動します。クライアントの名前を変更します。「新しい名前」の例「p1」を選択し、変更したセルの下のセルをクリックします。「len」列が変化していないことがわかります。ただし、len のあるセルをクリックすると、数値が正しい値に変化することがわかります。

誰でも理由がわかりますか？

jdk 1.5 と 1.6 (Java 6) のオブジェクトのシリアライズ (双方向通信) を混在させても安全かどうか疑問に思っています。私はこの質問に関する太陽からの明示的な声明を探しましたが、成功しませんでした. したがって、技術的な実現可能性に加えて、問題に関する「公式の」声明を探しています。

私たちは、独自のデザイナーで DesignSurface と IDesignerHost のすべての優れた機能を使用しています。設計されたフォームは、独自の特注フォーマットで永続化され、すべてうまく機能します。また、フォームをテキストベースの形式にエクスポートしたいと考えています (それほど難しくないため、これを実行しました)。

ただし、そのテキストをデザイナーのドキュメントにインポートして戻すことも必要です。これには、デザイナー コードを CodeCompileUnit に戻すことが含まれます。残念ながら、Parse メソッドは実装されていません (間違いなく正当な理由があります)。代替手段はありますか？標準の .NET インストールに存在しないもの (Visual Studio と共にインストールされる .NET ライブラリなど) は使用したくありません。

私の現在の考えは、インポートされたテキストをコンパイルし、フォームをインスタンス化し、そのプロパティとコントロールをデザイン サーフェイス オブジェクトにコピーして、新しい CodeCompileUnit をキャプチャすることですが、もっと良い方法があることを望んでいました。ありがとう。

更新: 私たちの進歩に興味を持っている人もいるかもしれません。これまでのところ、あまり良くありません。私が発見したことの簡単な概要は、難しすぎると見なされたために Parse メソッドが実装されなかったということです。作業を行うオープンソースのパーサーは存在しますが、それらは完全ではなく、したがってすべての場合に機能することが保証されているわけではありません ( NRefactory は SharpDevelop プロジェクトの 1 つだと思います)、インスタンスからデザイナーへのコントロールのコピーはまだ機能していません。これは、デザイナー サーフェイスがラップするフォーム インスタンスにコントロールが追加されているにもかかわらず、デザイナー サーフェイスがそのコントロールを認識していないためだと考えられます。私たちの次の試みは、カット/ペーストを模倣して、それが解決するかどうかを確認することです. 明らかに、これは非常に厄介な回避策ですが、機能させる必要があるため、'

フォーム上のメタデータのプレースホルダーとして設計された非ビジュアル コンポーネントを C# で作成しました。
コンポーネントには、カスタム オブジェクトのコレクションであるプロパティがあり、このオブジェクトは Serializable としてマークされており、シリアライズ用の GetObjectData とデシリアライズ用のパブリック コンストラクタを実装しています。

フォームの resx ファイルでは、コレクションを格納するためのバイナリ データが生成されますが、シリアル化されたクラスに変更を加えるたびにデザイナー エラーが発生し、resx ファイルからデータを手動で削除してから、このデータを再作成する必要があります。

クラス内の各プロパティの周りに try / catch ブロックを持つようにコンストラクターを変更しようとしました

しかし、それでもクラッシュします。最後のエラーは、IConvertible を実装する必要があるというものでした。

少なくともそれを見ることができるので、xml シリアライゼーションを使用したいと思いますが、デザイナーがこれを使用することは可能ですか?

シリアル化をより安定させ、変更に対する耐性を低くする方法はありますか?

編集：
詳細...より良い説明おそらく
、コンポーネントから継承するクラスがあり、ルールのコレクションである1つのプロパティがあります。RulesCollection は Serializable としてマークする必要があるようです。そうしないと、メンバーが保持されません。

Rules クラスは、コンポーネント トレイに表示されないようにする属性 DesignTimeVisible(false) を持つコンポーネントでもあります。このクラスは Serializable とマークされていません。

コレクションを Serializable としてマークすると、resx ファイルにバイナリ データが生成され (理想的ではありません)、IDE は Rules クラスが Serializable ではないことを報告します。

この問題は単純な質問を超えていると思います。ということで、近日中に閉めさせていただきます。
誰かが似たようなものへのリンクを持っていれば、それは大いに役立ちます。

WebService からカスタム クラスのインスタンスを返すときのシリアル化には、どのようなオプションがありますか?

使用法に応じて設定される場合とされない場合があるその他のプロパティと同様に、いくつかの子コレクション クラス プロパティを持ついくつかのクラスがあります。これらのオブジェクトは、ScriptService 属性で装飾された ASP.NET .asmx WebService から返されるため、さまざまな WebMethods によって返されるときに JSON シリアル化によってシリアル化されます。

問題は、すぐに使用できるシリアライゼーションが、使用されているかどうかに関係なく、すべてのパブリック プロパティを返し、クラス名やその他の情報を、必要な量を制限したい場合よりも詳細な方法で返すことです。トラフィック。

現在、返されるクラスに対して、JSON シリアル化を処理するカスタム JavaScript コンバーターを追加し、以下のように web.config に追加しました。

ただし、これにはクラスごとにカスタム コンバーターが必要です。サービスを拡張したり、カスタムシリアライザーを作成したりして、すぐに使用できる JSON シリアライゼーションを変更する他の方法はありますか?

フォローアップ
@marxidad:

他のアプリケーションで DataContractJsonSerializer クラスを使用していますが、これらのサービスに適用する方法がわかりません。サービスのセットアップ方法の例を次に示します。

WebMethods は JavaScript によって呼び出され、JSON でシリアル化されたデータを返します。シリアライゼーションを変更できる唯一の方法は、上記のように JavaScript コンバーターを使用することですか?

WebService にカスタム DataContractJsonSerializer を使用するように指示する方法はありますか? web.config 構成、属性によるサービスの装飾などによるものでしょうか?

更新
さて、上記のように個々の JavaScriptConverters を作成する以外に、すぐに使用できる JavaScriptSerializer を切り替える方法を見つけることができませんでした。

そのために、別のコンバーターを作成する必要がないようにするために行ったことは、汎用の JavaScriptConverter を作成することでした。処理したいクラスに空のインターフェイスを追加し、Web サービスの起動時に呼び出される SupportedTypes はリフレクションを使用して、次のようなインターフェイスを実装する型を見つけます。

実際の実装は少し異なり、型がキャッシュされるため、空のインターフェイスではなくカスタム属性を使用するようにリファクタリングする可能性があります。

ただし、これにより、カスタム コレクションを扱うときに、少し異なる問題に遭遇しました。これらは通常、一般的なリストを拡張するだけですが、List<> 自体の代わりにカスタム クラスが使用されます。これは、通常、コレクション クラスにカスタム ロジック、並べ替えなどがあるためです。

問題は、JavaScriptConverter の Serialize メソッドが、JSON にシリアル化された辞書を、関連付けられた型の名前と値のペアとして返すのに対し、リストは配列として返されることです。そのため、コンバーターを使用してコレクション クラスを簡単にシリアル化することはできませんでした。これに対する解決策は、これらの型をコンバーターの SupportedTypes に含めず、リストとして完全にシリアル化することでした。

したがって、シリアライゼーションは機能しますが、これらのオブジェクトを Web サービス呼び出しのパラメーターとして別の方法で渡そうとすると、デシリアライゼーションが中断されます。これは、入力を文字列/オブジェクト ディクショナリのリストとして扱うことができないためです。コレクションに含まれるカスタム クラスのリストに変換されません。これに対処する唯一の方法は、文字列/オブジェクト辞書のリストであるジェネリック クラスを作成し、そのリストを適切なカスタム コレクション クラスに変換し、代わりにジェネリック クラスを使用するように Web サービス パラメーターを変更することです。 .

ここには多くの問題や「ベスト プラクティス」の違反があると思いますが、大量のカスタム コンバーター クラスを作成しなくても問題は解決します。