Ben Weidig created TAP5-2758:
--------------------------------
Summary: Constructor/Builder injection should support @Symbol for
List/Collection/Map even without @Inject
Key: TAP5-2758
URL: https://issues.apache.org/jira/browse/TAP5-2758
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-ioc
Affects Versions: 5.8.3
Reporter: Ben Weidig
If a constructor/builder method for a Service that has any type of
configuration has also another {{{}List{}}}/{{{}Collection{}}}/{{{}Map{}}}, a
{{RuntimeException}} gets thrown
({{{}org.apache.tapestry5.ioc.internal.AbstractServiceCreator{}}}:95)
Adding @Symbol to the arguments doesn't help, it also requires {{@Inject}} to
work.
This behavior stems from
{{org.apache.tapestry5.ioc.internal.util.InternalUtils.calculateInjection(Class,
Type, Annotation[], ObjectLocator, InjectionResources)}} which analyzes
parameters and decides "how" to inject the value.
Symbols work because no other injection variant is found first.
However, if the parameter is a {{{}List{}}}/{{{}Collection{}}}/{{{}Map{}}},
it's always treated as a configuration, unless an {{@Inject}} is present.
In my opinion, this is not the best way to handle this.
{{@Symbol}} should be as significant as other annotations, as a symbol can't be
target of a configuration.
To not rely on the fallback, I propose adding a check for {{{}@Symbol{}}}.
My local proof of concept works but also highlighted the lack of tests for the
edge case of duplicate possible configuration parameters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
