Occasionaly, a tested class may have dependencies of different types which, in turn, have some other dependency of a type X, which need to be resolved to different instances of type X.
When using CDI or Spring DI, these X dependencies are usually qualified so they can be properly resolved. CDI's @nAmed, and Spring's @qualifier annotations are then used on fields of type X to specify the name of the desired instance.
So, when an injected field is annotated with @nAmed("name") or @qualifier("name"), JMockit should look for an @Injectable or @tested instance of the same type and "name", instead of using the regular searching rules (just the type, or type + injected field name).
The text was updated successfully, but these errors were encountered:
I was working with a colleague recently and we encountered a side effect of this implementation.
The application under test has beans with qualifiers containing dashes. Since this code expects the injectable variable to match the beanId we were in a bit of a pickle.
We worked around it by changing the @Qualifier annotation to @Resource but that may not always be a viable option, and it feels like a hack.
My question is: why not add an attribute to the @Injectable annotation that specifies the bean name in the scenario there are multiple auto-wire candidates?
I haven't dug into the code yet, but if you'll accept a PR to remedy this issue I'd be willing to try and make the contribution myself.
Occasionaly, a tested class may have dependencies of different types which, in turn, have some other dependency of a type X, which need to be resolved to different instances of type X.
When using CDI or Spring DI, these X dependencies are usually qualified so they can be properly resolved. CDI's @nAmed, and Spring's @qualifier annotations are then used on fields of type X to specify the name of the desired instance.
So, when an injected field is annotated with @nAmed("name") or @qualifier("name"), JMockit should look for an @Injectable or @tested instance of the same type and "name", instead of using the regular searching rules (just the type, or type + injected field name).
The text was updated successfully, but these errors were encountered: