[MAGNOLIA-6459] Overriding KeyGenerator does not work because system cannot handle more than one key generator Created: 10/Dec/15  Updated: 19/May/22  Resolved: 19/May/22

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

Type: Bug Priority: Neutral
Reporter: Bradley Andersen Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: i18n
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File keyGen.patch    
Issue Links:
dependency
is depended upon by JCRTOOLS-18 Add Custom i18n Key Generator Closed
Template:
Patch included:
Yes
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:
Story Points: 3

 Description   

The system defaults to a particular key generator. If you provide your own, the system simply bails because it doesn't know what to do when more than one key generator exists. This actually makes it impossible to use a custom key generator.

A patch which (strictly) fixes this issue by taking the last key generator in the Set is attached.

A more proper solution might be to not rely on this behavior, but rather to create a mapping of all such relationships, and, for each case, select the branch from the tree closest to the class under annotation.



 Comments   
Comment by Roman Kovařík [ 23/Dec/15 ]

We really need the closest class annotation, since it's a hash set so the order of items is not guaranteed. Why do we need a mapping btw?

Comment by Bradley Andersen [ 24/Dec/15 ]

I agree that a better long-term solution would be finding the 'closest' match: something implemented like a tree where the right annotation is the one with the shortest path from the current class.

WRT the HashSet, I believe ultimately in this case it is a LinkedHashMap, so that ordering is predictable.

Comment by Roman Kovařík [ 19/May/22 ]

Hello,

This ticket is now marked as closed due to one of the following reasons:

  • A long period of inactivity
  • Uses an old or Beta version of an application, module, or framework that we no longer support
  • The issue is no longer reproducible or has been fixed in later versions

If you are still facing a problem or consider this issue still relevant, please feel free to re-open the ticket and we will reach out to you.

Thank you,
The Magnolia Team

Generated at Mon Feb 12 04:14:43 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.