[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: |
|
| 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 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. To reproduce:
Possible track for patching this up: 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:
|
| 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. |