[
https://issues.apache.org/jira/browse/TAP5-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Weidig reassigned TAP5-2758:
--------------------------------
Assignee: Ben Weidig
> 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
> Assignee: Ben Weidig
> Priority: Minor
>
> 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)
