Follow-up on HSEARCH-3438. We may want to do it before the release because it would impact the mapping API.
Currently users can write this:
And it kind of makes sense, but it will fail at bootstrap, because AUTOMATIC can only be used if there is only one extractor.
We should improve the consistency between the API and the implementation: either we expose an API that does not even allow to express such things, or we change the implementation to support such things.
It shouldn't be too hard to support; the lower levels are probably ready, the main problem would be to modify ContainerExtractorPath to allow to represent the information (currently the whole path must represent "default extractors" (= automatic resolution), you can't model an automatic resolution mixed with explicit extractors.
It's really not clear what the use case for such an extractor chain would be. Why would you mention a few extractors explicitly, but use automatic resolution for the others?
We would still have some inconsistency in the APIs: sometimes a @ContainerValue annotation would refer to one extractor (explicit reference) sometimes it would refer to zero, one or multiple extractors (automatic resolution)
We could move up one level the place where automatic resolution is set, i.e.:
... but that's awfully verbose. Maybe the last one?
I'd like other solutions, because the two above are not very satisfying.