Hibernateの逆シリアル化の問題

Question

過去の他の人によって書かれ、デシリアライズの問題が発生しているいくつかの休止状態のコードを更新しようとしています。元のコードが書かれた方法は、それがserialVersionUIDを明示的に宣言し、ちょうどSerializableインタフェースを実装していませんでした -

public class SamplePOJO implements Serializable { 

を今、私はテーブルに新しい列を追加し、このオブジェクトにマップしようとしています。 I：

1. 変更された表
2. は、新しいStringオブジェクトとそのためのゲッター/セッター が含まれるように、オブジェクトを更新し、
3. が持つdbテーブルの列をマップするために.hbmファイルを更新し、新しい列を作成しますオブジェクト。

私は、コンパイル後にそれを実行したときしかし、私は次のエラーを取得する -

"Error while deserializing from byte[]., caused by x.y.SamplePOJO; local class incompatible: stream classdesc serialVersionUID = 7997933458932550222, local class serialVersionUID = <other number internally auto generated as source didn't explicitly mention serialVersionUID>" 

私は上記のエラーでスローされたものと一致するのserialVersionUIDが含まれるようにコードを更新した場合、それはどのなしで実行問題。

私が見つけた情報に基づいて、最も一般的な原因は、クライアントとサーバーの異なる休止状態のジャーに見えます。ただし、同じ休止状態のjarを使用しているため、ここでは該当しません。例外の間にスローされるserialVersionUIDを特に言及することなくこの問題を解決する方法がある場合、誰かを助けることができますか？また、私がこのアプローチに固執しなければならない場合、コードが別の環境（qa/prod）に移動すると、他の環境で直列化される方法に応じて異なるserialVersionUIDが期待されますか？

いずれか/すべてのヘルプをありがとう！

Answer 1

第2の質問にまず答えるために、JVMによる実行時のserialVersionUIDの生成は、Java Object Serialization Specificationで指定されています。実行時のserialVersionUIDの生成は予測可能ですが、コンパイラ実装固有のクラスファイルの構成に依存するため、Javaコンパイラ間で異なる可能性があります。したがって、コンパイルされたコードは、異なる環境で実行時に異なるserialVersionUIDを生成すべきではありません。 JDKのserialverコマンドを使用すると、クラスのランタイム生成serialVersionUIDを計算できます。

クライアントとサーバーで休止状態のjarファイルを持っていると、2つの異なるJVM間でエンティティをシリアル化しているように聞こえますが、クライアントには更新されたエンティティクラスがありますか？このエラーは、クラスファイルの異なるバージョンのシリアル化から生成されたbyte []を逆シリアル化しようとしていることを示します。同じバージョンのクラスにデシリアライズするか、serialVersionUIDをクラスに追加する必要があります。