[
https://issues.apache.org/jira/browse/TAP5-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17975464#comment-17975464
]
Hudson commented on TAP5-2758:
------------------------------
FAILURE: Integrated in Jenkins build Tapestry ยป tapestry-java-8-freestyle #55
(See
[https://ci-builds.apache.org/job/Tapestry/job/tapestry-java-8-freestyle/55/])
TAP5-2758: Treat @Symbol as explicit injection signal (benw: rev
3dc068e6a33a4fbb9ab36d383b32f08647f50f76)
* (edit)
tapestry-ioc/src/test/groovy/ioc/specs/ServiceBuilderMethodInvokerSpec.groovy
* (edit)
tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/internal/util/InternalUtils.java
* (edit)
tapestry-ioc/src/test/java/org/apache/tapestry5/ioc/test/internal/ServiceBuilderMethodFixture.java
* (add) tapestry-ioc/src/test/groovy/ioc/specs/DecorateWithSymbolSpec.groovy
* (add)
tapestry-ioc/src/test/java/org/apache/tapestry5/ioc/test/internal/DecorateWithSymbolModule.java
> 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)
