Spring Dependency Injection - An Introductory Tutorial
Using property place holder configurer
Let's say for each installation of an ATM, the installer may need to configure the number of retries. You probably don't want the installer messing with your XML file for your application context because it is too much like code and too many things could go wrong. Instead, perhaps you could just edit a properties file. The properties file could have properties for each of the things that may vary for a given installation of an AutomatedTellerMachineImpl.
atm.properties Properties file
transport.retries=8
applicationContext.xml using property-placeholder tag
<?xml version="1.0" encoding="UTF-8"?>
<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">
<context:property-placeholder location="classpath:atm.properties" />
<bean id="soapTransport" class="com.arcmind.springquickstart.SoapAtmTransport" p:retries="${transport.retries}"/>
<bean id="atm" class="com.arcmind.springquickstart.AutomatedTellerMachineImpl">
<constructor-arg index="0" ref="soapTransport" />
</bean>
</beans>
Notice the property-placeholder loads the atm.properties file from the classpath. Then you use the transport.retries defined in the atm.properties file as follows: p:retries="${transport.retries}".
Figure 9 illustrates using the property placeholder configurer.
You could load properties file from the file system using file: instead of classpath: in the location as follows:
Loading the properties file from the file system with the property-placeholder
<context:property-placeholder location="file:./src/main/resources/atm.properties" />
<bean id="soapTransport" class="com.arcmind.springquickstart.SoapAtmTransport" p:retries="${transport.retries}"/>
<bean id="atm" class="com.arcmind.springquickstart.AutomatedTellerMachineImpl">
<constructor-arg index="0" ref="soapTransport" />
</bean>
About the author
Rick Hightower is CTO of Mammatus and is an expert on Java and Cloud Computing. Rick is invovled in Java CDI advocacy and Java EE. CDI Implementations - Resin Candi - Seam Weld - Apache OpenWebBeans
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)





Comments
Murphree Mukada replied on Thu, 2008/11/27 - 7:48am
Rick Hightower replied on Sun, 2008/11/30 - 6:33pm
in response to:
George Jiang
Viraf Karai replied on Sat, 2009/02/21 - 3:14pm
Well written, but it might still be a tad difficult for newcomers to Spring to grasp fully.
I'm not in the anti-XML camp, so I don't feel very comfortable with this new trend towards using annotations willy-nilly. In fact I feel that it diminishes the ability to view the big picture. I do like the new 'context' and 'p' namespaces. Some of the annotations like @Required and @Transactional have been well-thought out by the SpringSource folks and I commend them for that.
Just one final note and it's not meant to be a sales pitch - IntelliJ IDEA 8.x has brilliant Spring support and provides really good code completion as well as linking Java interfaces with Spring bean definitions. I've been using it for about 8 months now and am continually amazed at it's capabilities.
Looking forward to your future articles - especially AOP - a great passion of mine.
Rick Reumann replied on Tue, 2009/09/01 - 2:54pm
I'm really curious though, how often do people have that many different implementations at application startup time? I've been using Spring and Guice for a while now and often when I've completed my app I look back and wonder "ok, what did I really gain here having my concrete implemenations defined in an xml or single Java file?"
I don't care much about using Mock objects in Testing either, but if I did, I could definitely see the advantage of DI there.
Of course I like containers doing some DI for me, like the EJB3 DI stuff etc, but in your typical CRUD app I simply find that I've added one more layer of abstraction that isn't needed. In the early days I was also always a purist and coded everything to an Interface - but in real life, how often, for example, are you swapping out Service class or DAO implemnations?
I feel like a heretic and wondering if I'm alone :)
Rick Hightower replied on Mon, 2011/03/28 - 11:27pm
in response to:
Cody A_
Pradeep Kumar replied on Wed, 2012/09/19 - 12:59pm
Very nice, no words thanks much..!!
But please add spring MVC 3.0 also.
Krishna Pokala replied on Tue, 2012/10/02 - 9:08am