@Inject and explicit defining

[GarfieldKlon]

Hi

I have this class:

public class AccountMailCredentialRecoveryManager extends
    AbstractUserCredentialRecoveryManager<Account>
{
    @Inject
    protected AccountService accountService;

    @Inject
    private TemplateMailService mailService;

    public void setAccountService(AccountService accountService)
    {
        this.accountService = accountService;
    }

    public void setMailService(TemplateMailService mailService)
    {
        this.mailService = mailService;
    }

}

and this spring config:

<bean id="CredentialRecoveryManager" class="ch.imis.ishop.authentication.AccountMailCredentialRecoveryManager">
    <property name="credentialEncryptor" ref="SaltCredentialEncryptor" />
    <property name="accountService" ref="AccountService" />
    <property name="messageTranslator" ref="MessageTranslator" />
    <property name="mailService" ref="CredentialRecoveryTemplateMailService" />
  </bean>

This results in:

Caused by: org.springframework.beans.factory.BeanCreationException: Could not autowire field: private ch.imis.ishop.mail.TemplateMailService ch.imis.ishop.authentication.AccountMailCredentialRecoveryManager.mailService; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [ch.imis.ishop.mail.TemplateMailService] is defined: expected single matching bean but found 5: [CredentialRecoveryTemplateMailService, templateMailService, registrationConfirmationMailService, efcoRegisterationMailService, RecommendationMailService]

Because there are other beans with the interface TemplateMailService. If I remove the @Inject it works. Is it the purpose that @Inject wins over the explicit property injection in the config file, or is this a bug?


greez
GarfieldKlon

[dehoric]

What this exception says is that spring doesn’t know what bean to inject. You have for that interface (TemplateMailService), more than one definition, and the @Inject works by type.
When you define that bean by XML, you says exactly what implementation will be used, so now the container can resolve it

[sumlight]

This is a little weird, below is quoted from Pro Spring 3:
Spring also supports a mix of the two approaches in a single ApplicationContext (the XML file configuration will override the annotation ones).