[MAGNOLIA-3837] Incompatible change in 4.4.5 breaks existing activation work items Created: 14/Sep/11  Updated: 13/Dec/11  Resolved: 09/Nov/11

Status: Closed
Project: Magnolia
Component/s: activation, core, workflow
Affects Version/s: 4.4.5
Fix Version/s: 4.4.6

Type: Bug Priority: Neutral
Reporter: Magnolia International Assignee: Ondrej Chytil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File pastie-2530958.txt    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

The code change introduced for MAGNOLIA-3693 makes it impossible to deserialize existing workitems which were created with 4.4.4 or earlier versions.

As such, just looking at the workflow "inbox" generates tons of exceptions. What's worse, proceeding with such work items will result in items not being deleted when they should. No content should be lost, but the removal of a paragraph, for example, won't be done. TODO: update this issue as soon as we know more.

To reproduce:

  • install a 4.4.4 instance (with workflow)
  • activate a page (don't "proceed" !)
  • upgrade to 4.4.5
  • open inbox (logs will show exception(s))
  • proceed activation

    * ????
    * profit !!

Possible track for patching this up:
Since we can't just revert the Rule class (because users might have started activations with the new class structure), we'd need to hook into the unserialization process. Something along those lines should work:

    private void readObject(ObjectInputStream ois) throws ClassNotFoundException, IOException {
        final ObjectInputStream.GetField field = ois.readFields();
        final Object o = field.get("allowedTypes", null);
        // here, if o is a String[], push into a Set, otherwise do nothing ...
    }

As a side note, I'd suggest we remove the serialVersionUID - had it not been there (or modified when code was changed, as it should have), the error log might have been a little cleared. I'd also suggest we don't "just" log the exception when unserializing the rule.

Classes and methods to look at:

  • info.magnolia.cms.core.version.ContentVersion#init
  • info.magnolia.cms.core.version.BaseVersionManager#getUsedFilter
  • info.magnolia.module.exchangesimple.ReceiveFilter#handleChildren


 Comments   
Comment by Jan Haderka [ 15/Sep/11 ]

Actually to ensure proper deserialization even after the changes, it is enough to fix the serialVersionUID of the class instead of letting compiler to generate it and then make sure that the class will properly react when encountering methods or variables that didn't exist in the older version. There should be no need to override readObject() method.

Comment by Magnolia International [ 15/Sep/11 ]

Uhm, between 4.4.4 and 4.4.5, the serialVersionUID was not changed (and existed with value 222 since long before that). The allowedTypes field was changed (from String[] to HashSet), and that's exactly why instances that were serialized with 4.4.4 can not be deserialized with 4.4.5. Without a custom readObject(ObjectInputStream, the JVM will not know how to deserialize "old" instances.

Comment by Magnolia International [ 15/Sep/11 ]

the exception, as seen when displaying the inbox

Comment by Ondrej Chytil [ 16/Sep/11 ]

Conclusion of testing is this bug is not messing up with any Magnolia functionality. Its only effect is exception thrown on accessing inbox. Then rule is created from defined allowed types and activation is proceeded correctly.

Comment by Ondrej Chytil [ 09/Nov/11 ]

Fixed by adding check if allowedTypes are still in String[] and converting them to hashset.

Generated at Mon Feb 12 03:50:08 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.