Has anyone tried to auto-wire different beans into a Spring-managed bean based on a condition? For e.g. if some condition is met, inject class A, else B? I saw in one of the Google search results that it is possible with SpEL (Spring Expression Language), but could not locate a working example.
Autowiring happens by placing an instance of one bean into the desired field in an instance of another bean. Both classes should be beans, i.e. they should be defined to live in the application context. What is "living" in the application context? This means that the context instantiates the objects, not you.
The XML-configuration-based autowiring functionality has five modes – no , byName , byType , constructor , and autodetect .
By default, Spring resolves @Autowired entries by type. If more than one bean of the same type is available in the container, the framework will throw a fatal exception. To resolve this conflict, we need to tell Spring explicitly which bean we want to inject.
There are multiple ways to achieve this. Mostly this depends on the conditioning you want to perform.
You can implement simple factory bean to do the conditional wiring. Such factory bean can contain complex conditioning logic:
public MyBeanFactoryBean implements FactoryBean<MyBean> { // Using app context instead of bean references so that the unused // dependency can be left uninitialized if it is lazily initialized @Autowired private ApplicationContext applicationContext; public MyBean getObject() { MyBean myBean = new MyBean(); if (true /* some condition */) { myBean.setDependency(applicationContext.getBean(DependencyX.class)); } else { myBean.setDependency(applicationContext.getBean(DependencyY.class)); } return myBean; } // Implementation of isSingleton => false and getObjectType }
Maybe a bit better approach is if you use factory bean to create the dependency bean in case you want to have only one such bean in your application context:
public MyDependencyFactoryBean implements FactoryBean<MyDependency> { public MyDependency getObject() { if (true /* some condition */) { return new MyDependencyX(); } else { return new MyDependencyY(); } } // Implementation of isSingleton => false and getObjectType }
With SpEL there are many possibilities. Most common are system property based conditions:
<bean class="com.example.MyBean"> <property name="dependency" value="#{systemProperties['foo'] == 'bar' ? dependencyX : dependencyY}" /> </bean>
You can have property placeholder resolve your bean reference. The dependency name can be part of the application configuration.
<bean class="com.example.MyBean"> <property name="dependency" ref="${dependencyName}" /> </bean>
Usually the condition you want to evaluate means that a whole set of beans should or should not be registered. Spring profiles can be used for this:
<!-- Default dependency which is referred by myBean --> <bean id="dependency" class="com.example.DependencyX" /> <beans profile="myProfile"> <!-- Override `dependency` definition if myProfile is active --> <bean id="dependency" class="com.example.DependencyY" /> </beans>
Other methods can mark the bean definition as lazy-init="true"
, but the definition will be still registered inside application context (and making your life harder when using unqualified autowiring). You can also use profiles with @Component
based beans via @Profile
annotation.
Check ApplicationContextInitialier
(or this example) to see how you can activate profiles programatically (i.e. based on your condition).
This is why Java based config is being so popular as you can do:
@Bean public MyBean myBean() { MyBean myBean = new MyBean(); if (true /* some condition */) { myBean.setDependency(dependencyX()); } else { myBean.setDependency(dependencyY()); } return myBean; }
Of course you can use more or less all configuration methods in the java based config as well (via @Profile
, @Value
or @Qualifier
+ @Autowired
).
Spring offers numerous hook points and SPIs, where you can participate in the application context life-cycle. This section requires a bit more knowledge of Spring's inner workings.
BeanFactoryPostProcessor
s can read and alter bean definitions (e.g. property placeholder ${}
resolution is implemented this way).
BeanPostProcessor
s can process bean instances. It is possible to check freshly created bean and play with it (e.g. @Scheduled
annotation processing is implemented this way).
MergedBeanDefinitionPostProcessor
is extension of bean post processor and can alter the bean definition just before it is being instantiated (@Autowired
annotation processing is implemented this way).
UPDATE Oct 2015
Spring 4 has added a new method how to do conditional bean registration via @Conditional
annotation. That is worth checking as well.
Of course there are numerous other ways with Spring Boot alone via its @ConditionalOn*
.
Also note that both @Import
and @ComponentScan
(and their XML counterparts) undergo property resolution (i.e. you can use ${}
).
I had a case where I needed to inject different beans depending on property: "my.property". In my case this solution was successful:
<property name="name" ref="#{ ${my.property:false}==true ? 'bean1' : 'bean2' }"/>
I needed to add the apostrophes around bean names in order to make it work.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With