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.
In lieu of a more complex solution, I’m taking the simplest approach, which is to implement a search of the tree for an ARC and if the ARC has a work context under it, it will return it.
This requires that one-off scenarios clean up their ARC, which is important anyway, so I don’t see this as a problem, it might help people catch those mistakes.
I checked the resolver, and it ensures the work context is removed, so we know that if it’s present, we have the “in progress” resolution.
Scott Cantor
September 4, 2024 at 5:10 PM
Notably, most of the use cases for the resolutionPhases feature basically don’t work, at least not fully. It’s possible to attach conditions that would run for “standard” resolution, but not conditions that would be evaluated properly during custom cases.
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.