[MGNLGROOVY-143] Rescue app is broken due to i18n not being set up Created: 04/Mar/16  Updated: 09/Feb/17  Resolved: 22/Jul/16

Status: Closed
Project: Magnolia Groovy Module
Component/s: console
Affects Version/s: 2.4.4
Fix Version/s: 2.4.5, 2.5

Type: Bug Priority: Major
Reporter: Mikaël Geljić Assignee: Ilgun Ilgun
Resolution: Fixed Votes: 0
Labels: rescue-app, support
Remaining Estimate: 7.5h
Time Spent: 3d 0.5h
Original Estimate: 4d

Attachments: Text File Logs from run.txt    
Issue Links:
causality
caused by MAGNOLIA-6721 Translation service throws NPE if it'... Closed
caused by MAGNOLIA-6556 TranslationService could be started o... Closed
relation
is related to MAGNOLIA-6724 TranslationService should not throw P... 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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Sprint: Basel 53
Story Points: 8

 Description   

Vaadin Terminal used in there tries to grab a SimpleTranslator, which is backed by TranslationService, which in turn requires the I18nModule via provider.

Observations

IMO problem is not the TranslationService is being instantiated properly or not. The problem appears to be the ModulesStartedEvent is not thrown and thus TranslationServiceImpl#messageBundles is null and therefore we have the NPE.

Had the ModulesStartedEvent fired in the rescue app solves the situation thus proves the observations above (With reverting I18nModule#isDebug in TranslationServiceImpl ). TranslationServiceImpl#messageBundles used to be populated upon each request and rightfully changed with MAGNOLIA-6556 in a way that ModulesStartedEvent is consumed in the TranslationServiceImpl's constructor and leads to population of the TranslationServiceImpl#messageBundles.

Proposed solution

1) Having TranslationServiceImpl#messageBundles populated explicitly in the rescue app via TranslationService#reloadMessageBundles()
2) Occurrences of i18nModuleProvider.get().isDebug() replaced with a method which returns false if i18nModuleProvider returns null or throws ProvisionException.

Steps to reproduce

  • Use a repository that is working with version 5.3 of magnolia.
  • Stop Mgnl and start a mgnl with version 5.4.7 on the 5.3 Mgnl repository
    Be sure to configure the web.xml to enable the groovy rescue servlet
  • When the server is up and running no groovy rescue servlet appears


 Comments   
Comment by Sang Ngo Huu [ 22/Mar/16 ]

I can run rescue app as well.

CE 5.4.6-SNAPSHOT
magnolia-module-groovy-2.4.3
Tomcat 7.0.55
Mac OSX 10.11.3
Java version "1.7.0_79"

Comment by Jan Haderka [ 29/Mar/16 ]

Could it be that you simply had older version of i18n w/ module class on the classpath? Just wild guess.

Comment by Jan Haderka [ 12/Jul/16 ]

evystup when reopening issue that was closed as "can't reproduce" you need to provide better instructions on how to reproduce the issue or it will get just closed again!

Comment by Roman Kovařík [ 13/Jul/16 ]

MgnlGroovyRescueApp is trying to use translation service which is not initialised yet. This should be rather fixed in the i18n module since it should fail gracefully (and e.g. return the key as the translation) instead of throwing NPE.

Comment by Jan Haderka [ 13/Jul/16 ]

But wouldn't that hide the problem? Imo we should either find a way to init translation service early enough so it can be used, or the rescue app should be non-translatable since it's emergency tool only.

Comment by Roman Kovařík [ 13/Jul/16 ]

But wouldn't that hide the problem?

An error would be logged.

we should either find a way to init translation service early enough

That's not possible since it requires the resource origin.

the rescue app should be non-translatable since it's emergency tool only

Agree, the rescue app is using the normal terminal but it should only use a terminal without translation service.

Comment by Roman Kovařík [ 18/Jul/16 ]

ilgun

IMO problem is not the TranslationService is being instantiated properly or not. The problem appears to be the ModulesStartedEvent is not thrown and thus TranslationServiceImpl#messageBundles is null and therefore we have the NPE. More information will follow.

I don't think the modules are started when using the rescue console thus the ModulesStartedEvent can't be thrown.

Comment by Roman Kovařík [ 22/Jul/16 ]

Reopened:

  • Missing dependency on i18n 5.4.8+
    OR
  • I was also wondering why we don't create translation service manually instead of getting it from component so we can provide a dummy i18n module provider and we don't have to have that ugly exception catch in i18n.
Comment by Philip Mundt [ 22/Jul/16 ]

rkovarik you're right about the dependency. However, it was like this before, therefore I vote for adding a QA commit to fix the dependency + the module descriptor (both on master and 2.4.x).

I believe this is due to the fact that at the time of the creation of the rescue app, i18n module didn't exist and was still part of core.

Closing the issue again. Adding QA commits...

Generated at Mon Feb 12 05:56:00 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.