[MAGNOLIA-5634] SecuritySupport will always be null when accessed prior to being initialized Created: 23/Jan/14  Updated: 11/Mar/16  Resolved: 23/Jan/14

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: 5.2.2

Type: Improvement Priority: Critical
Reporter: Daniel Lipp Assignee: Daniel Lipp
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MAGNOLIA-6593 resource-loader module throws NPE upo... Closed
dependency
is depended upon by MAGNOLIA-5625 Time of creation should be set automa... 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)
Date of First Response:

 Description   

With MAGNOLIA-5625 we try to retrieve the current User from MgnlContext earlier as we did before. Unfortunately SecuritySupport has not been instantiated at that time so it is null by then. We could cope with that situation (e.g. return null as User and not set createdBy) if later - once the SecuritySupport has been instantiated - we'd get the proper instance from our component provider. But as SecuritySupport is a Singleton we'll always get null now.

Best would be to define a default implementation for SecuritySupport that's just to be used in the initialization phase and will then be replaced by the configured one, once the later is available. We anyway know that for the initialization phase there's only one super -> the superuser.



 Comments   
Comment by Magnolia International [ 24/Jan/14 ]

Fixed by implementing a custom ObservedComponentFactory for SecuritySupport which returns a temporary instance until the configured one is available.

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