[MAGNOLIA-7003] CLONE - DefaultMessageBundlesLoader is always re-instantiated in order to reflect changes in message bundle Created: 05/Apr/17  Updated: 04/Mar/19

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

Type: Improvement Priority: Neutral
Reporter: Christian Ringele Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones MAGNOLIA-6725 DefaultMessageBundlesLoader is always... Closed
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)
Story Points: 5

 Description   

No matter what I do, changes in message bundles are not reloaded.
Using:
light-modules in a hybrid state (within a Maven module).
Only a restart of the server loads them (missing the old "reload message bundles" app ).

From the original ticket:
While QAing MAGNOLIA-6724 & MGNLGROOVY-143 we found that info.magnolia.i18nsystem.DefaultMessageBundlesLoader#logDuplicates and its verbose output in the log was printed twice – once upon component initialisation and once when calling info.magnolia.i18nsystem.TranslationServiceImpl#reloadMessageBundles.

The reason is that info.magnolia.i18nsystem.TranslationServiceImpl#setupMessageBundles creates a new instance of DefaultMessageBundlesLoader for each call, therefore omitting the component definition in META-INF/magnolia/i18n.xml of the i18n module.

It would be desirable to use

protected DefaultMessageBundlesLoader setupMessageBundles() {
    return componentProvider.getComponent(DefaultMessageBundlesLoader.class);
}

instead of

protected DefaultMessageBundlesLoader setupMessageBundles() {
    return componentProvider.newInstance(DefaultMessageBundlesLoader.class, resourceOrigin);
}

in order to only maintain one component and therefore preventing potential memory leaks.

However this will prevent for any changes in message properties files to be reflected in the translation service during runtime. Possible workaround could be to add the possibility to reload message property files in DefaultMessageBundlesLoader or make it aware of changes in origins (info.magnolia.resourceloader.ResourceOriginChange). Ideally we move registration of the event handler for ModulesStartedEvent to the component DefaultMessageBundlesLoader.

We should investigate and also find out why the new instance call was added in the first place and what impact above change could have.


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