You probably have some old Seam libs lying around. Check your build and deployment (clean build, delete and redeploy, etc.).
I have checked, we seem to be up to date.
Looking at the changes in Seam sources, it appears that on April 9, Pete Muir changed
private String triggerName;into
private final String triggerName;.
If that changes the serialVersionUID of QuartzTriggerHandle, then that would explain the problem. A patch for Seam would be to assign serialVersionUID so that those kinds of changes are automatically backward compatible.
By definition, Quartz triggers are meant to be stored in a database to be used later. So anything that breaks compatibility is a regression from my user's point of view.
Is my analysis correct?
Oh, I see now, You serialized and stored the QuartzHandle's. Changing the class would result in a new auto-generated serialVersionUID,
hence your problem. You should file a JIRA.
Btw, anouther alternative would be to not use QuartzTriggerHandle directly, but store Quartz job/trigger names (those are Strings,
so no problems there).
I'm trying to upgrade an app from Seam 2.0.2.SP1 to 2.2.0.GA and am running into this QuartzTriggerHandle deserialization problem. We have been storing the QuartzTriggerHandle as a LOB in our database and now that we've changed the class that I think is referenced in the LOB, we're getting deserialization errors. Is there any workaround or SEAM update that would allow us to deserialize these previously stored LOB's? Thanks for any help!