Bug 950461

Summary: Update serialVersionUID for criteria classes
Product: [Other] RHQ Project Reporter: Libor Zoubek <lzoubek>
Component: Core ServerAssignee: Nobody <nobody>
Status: ON_QA --- QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 4.6CC: hrupp, jshaughn, theute
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Libor Zoubek 2013-04-10 09:27:29 UTC 
Description of problem: 

I was having following issue:

I have a java client which depends on RHQ 4.6.0 artifacts, and I was running it agains RHQ 4.7.0-master or JON 3.2.Alpha build. I experienced strange behaviour of ResourceCriteria.

ResourceCriteria resourceCriteria = new ResourceCriteria();
resourceCriteria.addFilterId(10009);
resourceCriteria.fetchResourceType(true);
PageList<Resource> list = resourceManager.findResourcesByCriteria(client.getSubject(), resourceCriteria);
 
returns me 200 resources instead of just 1 like I didn't filter by ID at all. 

After investigation with lkrejci, we found out that most of *Criteria classes had been changed since 4.6.0. This weird behavior of Criteria happens because class is incorrectly de-serialized on server (I am using alot different class on client in sense of addFilterId ). But serialization does not fail at all, because serialVersionUID s are same.

all Criteria classes should be updated and should reflect the change. Then my client/server would fail to de-serialize given class.
Comment 1 Jirka Kremser 2013-04-10 12:35:00 UTC 
Nice catch! Looks like my commit (c5b87b9) broke it. According to [1], deleting a private member is considered as not (binary) backward compatible change. In fact, I just moved the private field from concrete classes to a common predecessor to be DRY, but from perspective of Java serialization it is considered as deletion of a field, thus incompatible change.

I guess, I am going to revert the c5b87b9 and wait for major release. Because the commit itself still does make a sense.

[1] http://docs.oracle.com/javase/7/docs/platform/serialization/spec/version.html#5172
Comment 2 Jay Shaughnessy 2013-04-10 14:25:01 UTC 

master commit c6c2d68b5e1fca8611d10d041cd5881cc58248ea
Author: Jay Shaughnessy <jshaughn>
Date:   Wed Apr 10 10:23:42 2013 -0400

    These are additional, non-criteria, domain classes that need a
    serialization ID update due to recent changes.
Comment 3 Jirka Kremser 2013-04-10 16:08:22 UTC 
branch:  master
link:    http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?id=39a6fc8
time:    2013-04-10 16:54:04 +0200
commit:  39a6fc85274cf27cfc7159dcd3af35daf2d8f84a
author:  Jirka Kremser - jkremser
message: [BZ 950461] - Update serialVersionUID for criteria classes -
         serialVersionUID++


The CLI client should be of the same version as the RHQ server. From now on, we are going to explicitly change the serialVersionUID whenever the change is made to a class which is subject of transfer over the wire (i.e. serialization and deserialization). So it shouldn't fail silently as it does in this case.
Comment 4 Jirka Kremser 2013-04-11 20:30:19 UTC 
4e40cf66e
3a2ec9413

https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?id=4e40cf66e
https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?id=3a2ec9413