Spring IoC: зависит-на переопределениях отложенной INIT

Question

прототипичный часть контекста приложения:

<bean id="option_A" class="class_a" lazy-init="true"/> 
<bean id="option_B" class="class_b" lazy-init="true" depends-on="setup_bean"/> 
<alias name="option_${OPTION_PROPERTY}" alias="thingChosen"/> 
<bean id="setup_bean" class="class_setup" lazy-init="true"/> 

Концепция здесь является то, что если OPTION_PROPERTY установлен в положение "A", а затем

<bean id="foo" class="whatever"><property name="bar" ref="thingChosen"/></bean> 

получит экземпляр класса_a, введенный в свойство bar, и если для свойства установлено значение «B», тогда он получит экземпляр класса b, введенный, но класс b имеет скрытую зависимость от setup_bean (какой класс отсутствует), поэтому setup_bean должен быть создан первым.

Что происходит, если для параметра OPTION_PROPERTY установлено значение «A», то setup_bean все еще создается. Я пробовал это, используя Spring 3.2.4.RELEASE, и это согласовано. Это похоже на ошибку или недоразумение с моей стороны.

Если фаза lazy-init, то не должна зависеть от фасоли ждать, пока этот бобы лениво не создаются до того, как будут созданы сами?

Answer 1

Если фасоль отложенной инициализации, то не должно зависит, от бобов ждать, пока что боб создан отложенно перед тем, как сами создали?

Да. Другими словами option_B не будет создан до тех пор, пока не будет запрошена и инициализирована setup_bean. Если сначала запрашивается option_B, то это приведет к инициализации setup_bean.

The documentation says

Однако, когда ленивая инициализация боб является зависимость одноплодной компонента, который не ленится-инициализирован, ApplicationContext создает ленивым инициализирован боб при запуске, так как она должна удовлетворять однопользовательских зависимостей.

Таким образом, этот компонент декларации

<bean id="foo" class="whatever"><property name="bar" ref="thingChosen"/></bean> 

заставит инициализацию thingChosen, который в этом случае псевдонима option_A.

Я не могу воспроизвести то, что вы испытываете (и не должно). Дважды проверьте, что вы делаете. Возможно, еще один компонент ссылается на setup_bean.

Вот SSCCE

public class Test { 
    public static void main(String[] args) throws Exception { 
     ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("spring.xml"); 
     System.out.println("context initialized"); 
     context.getBean("shouldnot"); 
    } 
    public static class MyClass { 
     public MyClass() { 
      System.out.println("myclass"); 
     } 
    } 
    public static class SetupBean { 
     public SetupBean() { 
      System.out.println("setup"); 
     } 
    } 
    public static class MyOtherClass { 
     private MyClass myClass; 
     public MyOtherClass() { 
      System.out.println("myotherclass"); 
     } 
     public MyClass getMyClass() { 
      return myClass; 
     } 
     public void setMyClass(MyClass myClass) { 
      this.myClass = myClass; 
     } 
    } 
} 

и spring.xml бобы

<bean id="myref" class="test.Test$MyClass" lazy-init="true"></bean> 
<bean id="shouldnot" class="test.Test$MyClass" lazy-init="true" depends-on="setup_bean"></bean> 

<bean class="test.Test$MyOtherClass" > 
    <property name="myClass" ref="myref"></property> 
</bean> 

<bean id="setup_bean" class="test.Test$SetupBean" lazy-init="true"></bean> 

печатает (минус пружинные журналы)

myotherclass 
myclass 
context initialized 
setup 
myclass 

Другими словами, setup только создаются, когда shouldnot запрашивается ,

Answer 2

Оказывается, что в другом месте в контексте, есть эта маленькая жемчужина:

<context:annotation-config /> 

Это, по-видимому, привожу к ленивой инициализации игнорируется.

Попытка выяснить, как работает отключающая техника, является следующим шагом, но выходит за рамки этого вопроса.