de-serialization problems

We have a production system that uses a lot of Serialization. What be basically do is store an object called ProcessData in the jbpm database as byte array. Thus this is serialized.

Consider the following Object.

public class ProcessData implements Serializable {
  private static final long serialVersionUID = -4859440951531011062L;

  public void getX() {
    //not important
  }
}

Now lets say we have this object stored in the JBPM database as byte array and we are using this in production.

Now later we want to upgrade this ProcessData object with a new data

public class ProcessData implements Serializable {
  private static final long serialVersionUID = -4859440951531011062L;

  public void getX() {
    //not important
  }

  public void getY() {
    //not important
  }
}

Now the problem is when JBPM loads the old stored ProcessData object, we get an exception Caused b开发者_运维技巧y: java.io.InvalidClassException: my.package.ProcessData; local class incompatible: stream classdesc serialVersionUID = 6651422488035743444, local class serialVersionUID = -7966721901330644987

Now my question is, how can we solve this problem? How can we make read the serialized object and sort of transform it in this new class. Is it even possible? Remember that we have limited control over the JBPM library.

It looks like you are not using the sample code in either case, since in your example you are defining the serialVersionUID (this is good) and it is the same before and after, but in your error, the UID's are different. For this to occur, the UID is either not defined (thus generated), or has been changed between versions. The generated case would also cause a change between versions since the class signatures are different.

In either case, this would be the expected behaviour.

It looks like the real code being run doesn't actually match your example. To load the old code, you will have to set the UID in the new version to match the one that already exists in the persisted classes (6651422488035743444L). Also, it is simpler to manage the UID's if you use simple numbers, like versions 1,2,3.