[MAGNOLIA-3811] FreemarkerConfig sharedVariables doesn't play well with content2bean Created: 25/Aug/11  Updated: 25/Aug/11  Resolved: 25/Aug/11

Status: Closed
Project: Magnolia
Component/s: core, freemarker
Affects Version/s: 4.4.4
Fix Version/s: 4.4.5

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

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

 Description   

In some cases, FreemarkerConfig's sharedVariables aren't populated properly by content2bean. It seems to be due to the order of methods (which can be lost/changed when hot deploying classes, for example).

FreemarkerConfig has two addSharedVariable methods, one of which takes an Object value (which is what c2b should use) and one which takes a Template model instance (which could be used in cases where we have a pre-wrapped object we want to expose).

This was done as a result of mistakenly thinking c2b would pick the most appropriate method, depending on the arguments (i.e like Java does naturally with method overloading). However, it's not the case: when looking for "add" methods, Content2bean uses the first one it finds with a matching name. In this case, and when source code order was preserved, it finds and uses (addSharedVariable(String name, Object value) and everything's peachy.

Obviously this highly depends on the order of the methods, i.e depends on how the code was compiled. In most cases, it seems the source order is kept, but probably when hot deploying classes, this order can change. As a result, c2b sometimes uses the addSharedVariable(String name, TemplateModel value method, which results in a reflection exception (arguments mismatch).

This has already been fixed on the trunk for 4.5 with SCRUM-30, so we'll apply the same fix on the 4.4 branch, simply removing the addSharedVariable(String name, TemplateModel value, which never worked.


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