[MAGNOLIA-6593] resource-loader module throws NPE upon clean install when using the empty-webapp Created: 11/Mar/16 Updated: 06/Dec/23 Resolved: 14/Dec/16 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | resource-loader |
| Affects Version/s: | 5.4.5 |
| Fix Version/s: | 5.4.11, 5.5.1 |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Philip Mundt | Assignee: | Hieu Nguyen Duc |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | support | ||
| Remaining Estimate: | 0d | ||
| Time Spent: | 7.75d | ||
| Original Estimate: | 5d | ||
| Attachments: |
|
||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||
| 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: | Saigon 74, Saigon 75 | ||||||||||||||||||||||||||||
| Story Points: | 5 | ||||||||||||||||||||||||||||
| Description |
| Comments |
| Comment by Daniel Kasmeroglu [ 21/Sep/16 ] |
I've checked this scenario now in greater detail and I can confirm that this is caused by a race condition. This issue occurs randomly on a clean install. However if I set a debugging breakpoint at the call of grantRepositoryToSuperuser the setup will be forced to wait there. Continuation after 1-2 seconds then doesn't show any problem. I've added a patched SetupModuleRepositoriesTask.java |
| Comment by Mikaël Geljić [ 30/Sep/16 ] |
|
Right, so SecuritySupport is an observed component/bound to an ObservedComponentFactory. Since default implementation is only set in core module bootstraps, we've basically got the install process relying on a deferred observation listener to provide the correct impl to other modules' DefaultModuleVersionHandler/SetupModuleRepositoriesTask. I'd argue observing components during the install phase is just prone to such mutations and should be delayed until the startup phase. |
| Comment by Will Scheidegger [ 18/Apr/18 ] |
|
I think we ran into the same problem yesterday, but this time when upgrading an EE installation from 5.3.8 zu 5.6.1 (not a clean install). After a restart, everything was fine again. What's the officially suggested procedure in this situation? Thanks! |
| Comment by Mikaël Geljić [ 20/Apr/18 ] |
|
Hey Will, hard to say without more info or logs; This ticket introduced an eager reloading of the SecuritySupport observed component, whenever an install task tries to do something with it and the registered instance is still the init-phase one (the one without a RoleManager). For which module/workspace did the task fail in your case? If the task executed fine upon restart, I expect the setup to be in proper state; you may double-check the superuser role's ACLs for explicit workspace access. |