Bug 950461 - Update serialVersionUID for criteria classes
Summary: Update serialVersionUID for criteria classes
Keywords:
Status: ON_QA
Alias: None
Product: RHQ Project
Classification: Other
Component: Core Server
Version: 4.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-10 09:27 UTC by Libor Zoubek
Modified: 2022-03-31 04:28 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.