[ 
https://issues.apache.org/jira/browse/TAP5-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747544#comment-17747544
 ] 

Ben Weidig commented on TAP5-2758:
----------------------------------

Even though I still think treating @Symbol this way is the correct choice, it's 
currently not possible to store a Collection Framework type in a Symbol, as 
Symbols are always type-coerced to String and back.

 

> 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)

Reply via email to