Can @Autowired e default-autowire coesistono?

Question

<beans default-autowire="byType /> 

significa che tutti i campi di fagioli avranno automaticamente le dipendenze iniettate se non c'è più di 1 bean con il tipo desiderato.

La domanda è: come funziona quando si utilizzano le annotazioni e funziona del tutto.

mio test ha dimostrato che, anche se uso

@Resource(name="someConcreteFoo") 
private Foo foo; 

contesto cerca di autowire campo per tipo e non riesce se ci sono più implementazioni di Foo. Quindi, per quello che vedo, default-autowire non si confonde con le annotazioni. Non ho trovato nulla di specifico nella documentazione.

Per estendere la domanda: come si comporta la molla con il default-autowiring quando si utilizza solo xml. Cioè se hai <property>. L'iniezione di proprietà sovrascrive il valore predefinito (dovrebbe essere).

Posso fare più test, ma preferirei che il comportamento fosse confermato da alcune citazioni. Qualche intuizione?

Answer 1

Edit:

fa l'iniezione di proprietà ignorare l'impostazione predefinita (dovrebbe essere).

Hai ragione. Se non si desidera che Spring estrae la dipendenza da un determinato campo di un bean, è possibile utilizzare l'annotazione @Qualifier per iniettare la dipendenza desiderata. Sto ancora cercando di trovare la documentazione che conferma — il più vicino ho potuto trovare è un post sul forum di primavera override default-autowire setting with an annotation?

Edit: Ecco un altro post @Resource considered only after default-autowire="byName" che descrive utilizzando una nuova InstantiationAwareBeanPostProcessor per cambiare l'ordine di cablaggio per avere @Resource on setter ha la precedenza su default-autowire.

Answer 2

Per quanto ne so, l'attributo autowire predefinito definisce la "modalità autowire" predefinita per quei bean cablati solo nella configurazione XML! Quindi l'autowiring basato sull'annotazione è indipendente da quello. @Autowired è sempre per tipo, @Resource è sempre per nome!
Vedere il suggerimento nella documentazione di riferimento di Spring 3.9.3:
"Se si intende esprimere l'iniezione guidata dall'annotazione per nome, non utilizzare principalmente @Autowired, anche se tecnicamente è in grado di fare riferimento a un nome di bean tramite @Qualifier valori, invece, usa l'annotazione JSR-250 @Resource, che è definita semanticamente per identificare un componente target specifico con il suo nome univoco, con il tipo dichiarato irrilevante per il processo di matching. "

Answer 3

Ho avuto una fitta veloce nel debug di questo problema, e penso che questo potrebbe essere un bug in primavera. A mio parere, il problema deriva da seguente codice nel AbstractAutowireCapableBeanFactory

/** 
* Populate the bean instance in the given BeanWrapper with the property values 
* from the bean definition. 
* @param beanName the name of the bean 
* @param mbd the bean definition for the bean 
* @param bw BeanWrapper with bean instance 
*/ 
protected void populateBean(String beanName, AbstractBeanDefinition mbd, BeanWrapper bw) { 
    PropertyValues pvs = mbd.getPropertyValues(); 

    if (bw == null) { 
     if (!pvs.isEmpty()) { 
      throw new BeanCreationException(
        mbd.getResourceDescription(), beanName, "Cannot apply property values to null instance"); 
     } 
     else { 
      // Skip property population phase for null instance. 
      return; 
     } 
    } 

    // Give any InstantiationAwareBeanPostProcessors the opportunity to modify the 
    // state of the bean before properties are set. This can be used, for example, 
    // to support styles of field injection. 
    boolean continueWithPropertyPopulation = true; 

    if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) { 
     for (BeanPostProcessor bp : getBeanPostProcessors()) { 
      if (bp instanceof InstantiationAwareBeanPostProcessor) { 
       InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp; 
       if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) { 
        continueWithPropertyPopulation = false; 
        break; 
       } 
      } 
     } 
    } 

    if (!continueWithPropertyPopulation) { 
     return; 
    } 

    if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME || 
      mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) { 
     MutablePropertyValues newPvs = new MutablePropertyValues(pvs); 

     // Add property values based on autowire by name if applicable. 
     if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME) { 
      autowireByName(beanName, mbd, bw, newPvs); 
     } 

     // Add property values based on autowire by type if applicable. 
     if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) { 
      autowireByType(beanName, mbd, bw, newPvs); 
     } 

     pvs = newPvs; 
    } 

    boolean hasInstAwareBpps = hasInstantiationAwareBeanPostProcessors(); 
    boolean needsDepCheck = (mbd.getDependencyCheck() != RootBeanDefinition.DEPENDENCY_CHECK_NONE); 

    if (hasInstAwareBpps || needsDepCheck) { 
     PropertyDescriptor[] filteredPds = filterPropertyDescriptorsForDependencyCheck(bw); 
     if (hasInstAwareBpps) { 
      for (BeanPostProcessor bp : getBeanPostProcessors()) { 
       if (bp instanceof InstantiationAwareBeanPostProcessor) { 
        InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp; 
        pvs = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName); 
        if (pvs == null) { 
         return; 
        } 
       } 
      } 
     } 
     if (needsDepCheck) { 
      checkDependencies(beanName, mbd, filteredPds, pvs); 
     } 
    } 

    applyPropertyValues(beanName, mbd, bw, pvs); 
} 

Personalmente penso che l'ordine di applicare l'autowiring e InstantiationAwareBeanPostProcessor è sbagliato, come l'annotazione @Resource verrebbe applicata solo nei postProcessPropertyValues, così dopo l'autowiring (a partire da quel momento il autowiring ha già fallito).

Ora non so se ci sarebbe un impatto nel cambiare l'ordine delle invocazioni, in modo che le annotazioni @Resource siano risolte prima dell'autowiring, ma questo potrebbe essere un qualcosa da sollevare come bug/correzione (ho usato il seguente modo di caricare mio contesto applicazione di test per risolvere questo problema):

ApplicationContext ctx = new ClassPathXmlApplicationContext("test/appctx.xml") { 
     protected org.springframework.beans.factory.support.DefaultListableBeanFactory createBeanFactory() { 
      return new DefaultListableBeanFactory(getInternalParentBeanFactory()) { 
       protected void populateBean(String beanName, org.springframework.beans.factory.support.AbstractBeanDefinition mbd, org.springframework.beans.BeanWrapper bw) { 
        PropertyValues pvs = mbd.getPropertyValues(); 

        if (bw == null) { 
         if (!pvs.isEmpty()) { 
          throw new BeanCreationException(
            mbd.getResourceDescription(), beanName, "Cannot apply property values to null instance"); 
         } 
         else { 
          // Skip property population phase for null instance. 
          return; 
         } 
        } 

        // Give any InstantiationAwareBeanPostProcessors the opportunity to modify the 
        // state of the bean before properties are set. This can be used, for example, 
        // to support styles of field injection. 
        boolean continueWithPropertyPopulation = true; 

        if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) { 
         for (BeanPostProcessor bp : getBeanPostProcessors()) { 
          if (bp instanceof InstantiationAwareBeanPostProcessor) { 
           InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp; 
           if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) { 
            continueWithPropertyPopulation = false; 
            break; 
           } 
          } 
         } 
        } 

        if (!continueWithPropertyPopulation) { 
         return; 
        } 

        boolean hasInstAwareBpps = hasInstantiationAwareBeanPostProcessors(); 
        boolean needsDepCheck = (mbd.getDependencyCheck() != RootBeanDefinition.DEPENDENCY_CHECK_NONE); 

        if (hasInstAwareBpps || needsDepCheck) { 
         PropertyDescriptor[] filteredPds = filterPropertyDescriptorsForDependencyCheck(bw); 
         if (hasInstAwareBpps) { 
          for (BeanPostProcessor bp : getBeanPostProcessors()) { 
           if (bp instanceof InstantiationAwareBeanPostProcessor) { 
            InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp; 
            pvs = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName); 
            if (pvs == null) { 
             return; 
            } 
           } 
          } 
         } 
         if (needsDepCheck) { 
          checkDependencies(beanName, mbd, filteredPds, pvs); 
         } 
        } 

        if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME || 
          mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) { 
         MutablePropertyValues newPvs = new MutablePropertyValues(pvs); 

         // Add property values based on autowire by name if applicable. 
         if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME) { 
          autowireByName(beanName, mbd, bw, newPvs); 
         } 

         // Add property values based on autowire by type if applicable. 
         if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) { 
          autowireByType(beanName, mbd, bw, newPvs); 
         } 

         pvs = newPvs; 
        } 

        applyPropertyValues(beanName, mbd, bw, pvs); 
       } 
      }; 
     } 
    }; 

Speranza che aiuta