[MGNLUI-4932] CT based app fails to start with NPE (on cloud) Created: 04/Jan/19  Updated: 19/Mar/19  Resolved: 07/Feb/19

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

Type: Bug Priority: Neutral
Reporter: Christoph Meier Assignee: Robert Šiška
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: 0d
Time Spent: 2h 14m
Original Estimate: Not Specified
Environment:

Cloud;
Integration, group-5_site-1 -> https://author-integration-group5-site1.int.magnolia-cloud.com ;
working with user9.


Attachments: Text File appLaunch-failure-stackTrace.txt     Text File from_magnolia-debug-log.txt    
Issue Links:
dependency
depends upon MAGNOLIA-7445 Re-resolve yaml definition when depen... Closed
duplicate
is duplicated by MGNLCT-84 Git clone operation may register app ... 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:
Epic Link: Content Types finalization
Sprint: Foundation 2, Foundation 3, Foundation 4
Story Points: 8

 Description   

Observation and error

Attempts to launch CT-based apps on cloud fail with a nullpointer exception.
All three apps from the used example (see below) fail to start.
App label is not translated, and the app icon shows the fallback (but should show default) in the example.

The definitions app does not indicate errors neither for the CT definitions nor for the CT-based app definitions.
But:
apps are not correctly registered, they don't have any raw-view in definitions app.
Creating a "hot-fix" for tourVehicles, without editing, is fixing the issue. Also icon and label are correct after the hot-fix.

See the attached file appLaunch-failure-stackTrace.txt for the complete stackTrace as shown in the messages app as problem.
I cannot provide a more detailled log, since the given cloud env. currently doesn't provide log entries.

 

Used example

content-type-examples light module (GIT).

More resources

https://documentation.magnolia-cms.com/display/~cmeier/Using+content+types+and+CT+based+apps+on+6.0-SNAPSHOT+at+cloud

 



 Comments   
Comment by Christoph Meier [ 08/Jan/19 ]

mgeljic

I have just confirmed with mdrapela - all the symptoms which I have described in this ticket and on the WIKI page (https://wiki.magnolia-cms.com/display/~cmeier/Using+content+types+and+CT+based+apps+on+6.0-SNAPSHOT+at+cloud) are fully identical to what Martin has observed and described in MGNLCT-84

Hence - we can mark either this ticket or MGNLCT-84 as duplicate.

Comment by Mikaël Geljić [ 08/Jan/19 ]

Actually, we use the YAML-file dependency mechanism between the app file & the contentType file; so in theory, the app should have been reloaded after contentType was registered.
However, the YamlFileDependency "link" is only created after the contentType existence check.

Two main problems here:

  • not sure if YamlFileDependency supports a non-existing path and reports when that path is actually created
  • dependent path is not known yet before CT def exists (fetched from CT definition metadata); could we live with a convention here?
    • lookup for a CT in the same module as the app, and with file name equal to the definition name?
Comment by Mikaël Geljić [ 20/Feb/19 ]

No problem in definitions app indeed, since app is re-resolved.

Comment by Martin Drápela [ 19/Mar/19 ]

Just an observation in the context of this and the original MGNLCT-84: running Magnolia 6.0 on Websphere Liberty 19.0.0.2 - there's no issue with this, no problem is reported in the Definitions app.

Generated at Mon Feb 12 09:21:33 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.