[MGNLIMG-137] BinaryNodeParameterProviderFactory doesn't follow ParameterProviderFactory contract and is thus at risk of generating the same image multiple times Created: 20/Aug/14  Updated: 13/Sep/17  Resolved: 13/Sep/17

Status: Closed
Project: Imaging
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Magnolia International Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
relation
is related to MGNLIMG-201 Concurrent image generation jobs gene... Accepted
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

 Description   

From ParameterProviderFactory's javadoc:

 * The ParameterProviderFactory must also ensure the parameter has appropriate 
 * equals() and hashCode() methods: the parameter is used as part of a key of a
 * blocking map to avoid generating the same image multiple times.

Here, "the parameter" should read "the parameter, as returned by ParameterProvider.getParameter()".

In earlier implementations based on the Content API, we were wrapping the Content/NodeData instances with SimpleEqualityContentWrapper (or SimpleEqualityNodeDataWrapper), which provides an equals() and hashcode() implementation that did the trick.

However, BinaryNodeParameterProviderFactory does no such thing, thus relying on the equals() and hashCode() implementations of the given Node, which is not specified, and not likely to do what we want (e.g 2 Node instances from a different Session are not considered equal)


Generated at Mon Feb 12 02:12:39 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.