Resolution predicates can't handle non-default location of contexts
Basics
Logistics
Basics
Logistics
Description
There’s a chicken and egg problem with the design in cases where the relative locations of the PRC and ARC are not “defaulted”.
You can inject a lookup strategy for locating the PRC from the ARC by populating it into the ARC at runtime, because the caller knows where the PRC is to be found. But a statically configured Predicate used as an activation condition that needs to locate the ARC from the PRC is stuck because the lookup there is populated at configuration time (or in many cases defaulted only because it’s implicitly created by Spring parsing).
An example is the resolutionPhases condition, but anything that inherits from AbstractAttributeResolutionLookupFunction has the problem.
I…do not know if it’s fixable, it’s definitely not obvious.
There’s a chicken and egg problem with the design in cases where the relative locations of the PRC and ARC are not “defaulted”.
You can inject a lookup strategy for locating the PRC from the ARC by populating it into the ARC at runtime, because the caller knows where the PRC is to be found. But a statically configured Predicate used as an activation condition that needs to locate the ARC from the PRC is stuck because the lookup there is populated at configuration time (or in many cases defaulted only because it’s implicitly created by Spring parsing).
An example is the resolutionPhases condition, but anything that inherits from
AbstractAttributeResolutionLookupFunctionhas the problem.I…do not know if it’s fixable, it’s definitely not obvious.