Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix creation of superfluous
PanDomainAuthSettingsRefresher
instances
Having `def panDomainSettings: PanDomainAuthSettingsRefresher` in the `AuthActions` trait as a `def` means that implementors of `AuthActions` are able to make the mistake of also defining their implementation of that field as a `def`, meaning that every reference to it can potentially create _another_ instance of the refresher, as seen here: guardian/atom-workshop#361 (comment) Surprisingly, this seems to have been a problem since at least as far back as #41 in February 2018. Changing the field type to `val` forces implementers to also use `val` for that field, effectively making it a singleton, as we want. Changing the abstract field of a trait to be `val` does open up another danger due the initialization order of vals - the field could end up being evaluated as `null` if the trait immediately evaluates the field: See: https://docs.scala-lang.org/tutorials/FAQ/initialization-order.html ...consequently, I've made all `val` declarations in the `AuthActions` trait (that evaluate `panDomainSettings` in some way) into `lazy val`s. This hopefully should fix the problem.
- Loading branch information
Although
system
&domain
could have remained asdef
s, the truth is that they are constantval
members ofPanDomainAuthSettingsRefresher
, so they can not change - consequently, they might as well belazy val
s (but they must belazy
, as otherwise that would immediately evaluatepanDomainSettings
at construction time, which we want to avoid).