[
https://issues.apache.org/jira/browse/TAP5-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17944163#comment-17944163
]
ASF subversion and git services commented on TAP5-2758:
-------------------------------------------------------
Commit 3dc068e6a33a4fbb9ab36d383b32f08647f50f76 in tapestry-5's branch
refs/heads/master from Ben Weidig
[ https://gitbox.apache.org/repos/asf?p=tapestry-5.git;h=3dc068e6a ]
TAP5-2758: Treat @Symbol as explicit injection signal
The @Symbol annotation should be an explicit injection signal and not be
autowired. That allows using @Symbol without an additional @Inject to
force the behavior in certain scenarios.
> 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)
