Getting Started With Spring Framework, Second Edition J Sharma Ashish Sarin Framework A Hands On Guide To Begin Developing Ap

User Manual:

Open the PDF directly: View PDF .
Page Count: 517 [warning: Documents this large are best viewed by clicking the View PDF Link!]

Preface
Chapter 1 – Introduction to Spring Framework
Chapter 2 – Spring Framework basics
Chapter 3 - Configuring beans
Chapter 4 - Dependency injection
Chapter 5 - Customizing beans and bean definitions
Chapter 6- Annotation-driven development with Spring
Chapter 7 - Database interaction using Spring
Chapter 8 - Messaging, emailing, asynchronous method execution, and caching using Spring
Chapter 9 - Aspect-oriented programming
Chapter 10 – Spring Web MVC basics
Chapter 11 – Validation and data binding in Spring Web MVC
Chapter 12 –Developing RESTful web services using Spring Web MVC
Chapter 13 – More Spring Web MVC – internationalization, file upload and asynchronous request processing
Chapter 14 – Securing applications using Spring Security
Appendix A – Importing and deploying sample projects in Eclipse IDE (or IntelliJ IDEA)

GettingstartedwithSpringFramework

SecondEdition



AshishSarin,JSharma


Tableofcontents
Preface
Howtousethisbook
Conventionsusedinthisbook
Feedbackandquestions
Abouttheauthors
Chapter1–IntroductiontoSpringFramework
1-1Introduction
1-2SpringFrameworkmodules
1-3SpringIoCcontainer
1-4BenefitsofusingSpringFramework
Consistentapproachtomanaginglocalandglobaltransactions
Declarativetransactionmanagement
Security
JMX(JavaManagementExtensions)
JMS(JavaMessageService)
Caching
1-5AsimpleSpringapplication
Identifyingapplicationobjectsandtheirdependencies
CreatingPOJOclassescorrespondingtoidentifiedapplicationobjects
Creatingtheconfigurationmetadata
CreatinganinstanceofSpringcontainer
AccessbeansfromtheSpringcontainer
1-6FrameworksbuiltontopofSpring
1-7Summary
Chapter2–SpringFrameworkbasics
2-1Introduction
2-2Programmingtointerfacesdesignprinciple
Scenario:Dependentclasscontainsreferencetotheconcreteclassofdependency
Scenario:Dependentclasscontainsreferencetotheinterfaceimplementedbythe
dependency
Spring’ssupportfor‘programmingtointerfaces’designapproach

2-3DifferentapproachestoinstantiatingSpringbeans
Instantiatingbeansviastaticfactorymethods
Instantiatingbeansviainstancefactorymethods
2-4Dependencyinjectiontechniques
Setter-basedDI
Constructor-basedDI
2-5Beanscopes
Singleton
Prototype
Choosingtherightscopeforyourbeans
2-6Summary
Chapter3-Configuringbeans
3-1Introduction
3-2Beandefinitioninheritance
MyBank–Beandefinitioninheritanceexample
Whatgetsinherited?
3-3Constructorargumentmatching
Passingsimplevaluesandbeanreferencesusing<constructor-arg>element
Constructorargumentmatchingbasedontype
Constructorargumentmatchingbasedonname
3-4Configuringdifferenttypesofbeanpropertiesandconstructorarguments
Built-inpropertyeditorsinSpring
Specifyingvaluesfordifferentcollectiontypes
Specifyingvaluesforarrays
Defaultcollectionimplementationfor<list>,<set>and<map>elements
3-5Built-inpropertyeditors
CustomCollectionEditor
CustomMapEditor
CustomDateEditor
3-6RegisteringpropertyeditorswiththeSpringcontainer
CreatingaPropertyEditorRegistrarimplementation
ConfiguringtheCustomEditorConfigurerclass
3-7Concisebeandefinitionswithpandcnamespaces
p-namespace
c-namespace
3-8Spring’sutilschema

<list>
<map>
<set>
<properties>
<constant>
<property-path>
3-9FactoryBeaninterface
MyBankapplication–Storingeventsinthedatabase
MyBank–FactoryBeanexample
AccessingtheFactoryBeaninstance
3-10Summary
Chapter4-Dependencyinjection
4-1Introduction
4-2Innerbeans
4-3Explicitlycontrollingthebeaninitializationorderwithdepends-onattribute
MyBank–implieddependenciesbetweenbeans
Implicitdependencyproblem
4-4Singleton-andprototype-scopedbean’sdependencies
Singleton-scopedbean’sdependencies
Prototype-scopedbean’sdependencies
4-5Obtainingnewinstancesofprototypebeansinsidesingletonbeans
ApplicationContextAwareinterface
<lookup-method>element
<replaced-method>element
4-6Autowiringdependencies
byType
constructor
byName
default/no
Makingbeansunavailableforautowiring
Autowiringlimitations
4-7Summary
Chapter5-Customizingbeansandbeandefinitions
5-1Introduction
5-2Customizingbean’sinitializationanddestructionlogic

MakingSpringinvokecleanupmethodspecifiedbythedestory-methodattribute
Cleanupmethodsandprototype-scopedbeans
Specifyingdefaultbeaninitializationanddestructionmethodsforallbeans
InitializingBeanandDisposableBeanlifecycleinterfaces
JSR250’s@PostConstructand@PreDestroyannotations
5-3InteractingwithnewlycreatedbeaninstancesusingBeanPostProcessor
BeanPostProcessorexample–Validatingbeaninstances
BeanPostProcessorexample–Resolvingbeandependencies
BeanPostProcessorbehaviorforFactoryBeans
RequiredAnnotationBeanPostProcessor
DestructionAwareBeanPostProcessor
5-4ModifyingbeandefinitionsusingBeanFactoryPostProcessor
BeanFactoryPostProcessorexample
PropertySourcesPlaceholderConfigurer
PropertyOverrideConfigurer
5-5Summary
Chapter6-Annotation-drivendevelopmentwithSpring
6-1Introduction
6-2IdentifyingSpringcomponentswith@Component
6-3@Autowired-autowiringdependenciesbytype
6-4@Qualifier–autowiringdependenciesbyname
6-5JSR330’s@Injectand@Namedannotations
6-6JSR250’s@Resourceannotation
6-7@Scope,@Lazy,@DependsOnand@Primaryannotations
6-8Simplifyingcomponentconfigurationusing@Valueannotation
6-9ValidatingobjectsusingSpring’sValidatorinterface
6-10SpecifyingconstraintsusingJSR303annotations
JSR303supportinSpring
6-11ProgrammaticallyconfiguringSpringbeansusing@Configurationand@Bean
annotations
6-12Summary
Chapter7-DatabaseinteractionusingSpring
7-1Introduction
7-2MyBankapplication’srequirements

7-3DevelopingtheMyBankapplicationusingSpring’sJDBCmodule
Configuringadatasource
CreatingDAOsthatuseSpring’sJDBCmoduleclasses
7-4DevelopingtheMyBankapplicationusingHibernate
ConfiguringSessionFactoryinstance
CreatingDAOsthatuseHibernateAPIfordatabaseinteraction
7-5TransactionmanagementusingSpring
MyBank’stransactionmanagementrequirements
Programmatictransactionmanagement
Declarativetransactionmanagement
Spring’ssupportforJTA
7-6Summary
Chapter8-Messaging,emailing,asynchronousmethodexecution,andcachingusing
Spring
8-1Introduction
8-2MyBankapplication’srequirements
8-3SendingJMSmessages
ConfiguringActiveMQbrokertoruninembeddedmode
ConfiguringaJMSConnectionFactory
SendingJMSmessagesusingJmsTemplate
SendingJMSmessageswithinatransaction
DynamicJMSdestinationsandJmsTemplateconfiguration
JmsTemplateandmessageconversion
8-4ReceivingJMSmessages
SynchronouslyreceivingJMSmessagesusingJmsTemplate
AsynchronouslyreceivingJMSmessagesusingmessagelistenercontainers
8-5Sendingemails
8-6Taskschedulingandasynchronousexecution
TaskExecutorinterface
TaskSchedulerinterface
@Asyncand@Scheduledannotations
8-7Caching
ConfiguringaCacheManager
Cachingannotations-@Cacheable,@CacheEvictand@CachePut
8-8RunningtheMyBankapplication
8-9Summary

Chapter9-Aspect-orientedprogramming
9-1Introduction
9-2AsimpleAOPexample
9-3SpringAOPframework
Proxycreation
expose-proxyattribute
9-4Pointcutexpressions
@Pointcutannotation
executionandargspointcutdesignators
beanpointcutdesignator
Annotations-basedpointcutdesignators
9-5Advicetypes
Beforeadvice
Afterreturningadvice
Afterthrowingadvice
Afteradvice
Aroundadvice
9-6SpringAOP-XMLschema-style
ConfiguringanAOPaspect
Configuringanadvice
Associatingapointcutexpressionwithanadvice
9-7Summary
Chapter10–SpringWebMVCbasics
10-1Introduction
10-2Directorystructureofsamplewebprojects
10-3Understandingthe‘HelloWorld’webapplication
HelloWorldController.java–HelloWorldwebapplication’scontrollerclass
helloworld.jsp–JSPpagethatshowsthe‘HelloWorld!!’message
myapp-config.xml–WebapplicationcontextXMLfile
web.xml–Webapplicationdeploymentdescriptor
10-4DispatcherServlet–thefrontcontroller
AccessingServletContextandServletConfigobjects
10-5Developingcontrollersusing@Controllerand@RequestMappingannotations
Developinga‘HelloWorld’webapplicationusinganannotatedcontroller
10-6MyBankwebapplication’srequirements

10-7SpringWebMVCannotations-@RequestMappingand@RequestParam
Mappingrequeststocontrollersorcontrollermethodsusing@RequestMapping
@RequestMappingannotatedmethodsarguments
@RequestMappingannotatedmethodsreturntypes
Passingrequestparameterstocontrollermethodsusing@RequestParam
10-8Validation
10-9Handlingexceptionsusing@ExceptionHandlerannotation
10-11LoadingrootwebapplicationcontextXMLfile(s)
10-12Summary
Chapter11–ValidationanddatabindinginSpringWebMVC
11-1Introduction
11-2Addingandretrievingmodelattributesusing@ModelAttributeannotation
Addingmodelattributesusingmethod-level@ModelAttributeannotation
Retrievingmodelattributesusing@ModelAttributeannotation
Requestprocessingand@ModelAttributeannotatedmethods
Behaviorof@ModelAttributeannotatedmethodarguments
RequestToViewNameTranslator
11-3Cachingmodelattributesusing@SessionAttributesannotation
11-4DatabindingsupportinSpring
WebDataBinder–databinderforwebrequestparameters
ConfiguringaWebDataBinderinstance
Allowingordisallowingfieldsfromdatabindingprocess
InspectingdatabindingandvalidationerrorsusingBindingResultobject
11-5ValidationsupportinSpring
ValidatingmodelattributesusingSpring’sValidatorinterface
SpecifyingconstraintsusingJSR303annotations
ValidatingobjectsthatuseJSR303annotations
11-6Spring’sformtaglibrary
HTML5supportinSpring’sformtaglibrary
11-7Summary
Chapter12–DevelopingRESTfulwebservicesusingSpringWebMVC
12-1Introduction
12-2Fixeddepositwebservice
12-3ImplementingaRESTfulwebserviceusingSpringWebMVC

JSON(JavaScriptObjectNotation)
FixedDepositWSwebserviceimplementation
12-4AccessingRESTfulwebservicesusingRestTemplate
12-5ConvertingJavaobjectstoHTTPrequestsandresponsesandviceversausing
HttpMessageConverter
12-6@PathVariableand@MatrixVariableannotations
12-7Summary
Chapter13–MoreSpringWebMVC–internationalization,fileuploadand
asynchronousrequestprocessing
13-1Introduction
13-2Pre-andpost-processingrequestsusinghandlerinterceptors
Implementingandconfiguringahandlerinterceptor
13-3Internationalizingusingresourcebundles
MyBankwebapplication’srequirements
InternationalizingandlocalizingMyBankwebapplication
13-4Asynchronouslyprocessingrequests
Asynchronousrequestprocessingconfiguration
ReturningCallablefrom@RequestMappingmethods
ReturningDeferredResultfrom@RequestMappingmethods
Settingdefaulttimeoutvalue
Interceptingasynchronousrequests
13-5TypeconversionandformattingsupportinSpring
CreatingacustomConverter
ConfiguringandusingacustomConverter
CreatingacustomFormatter
ConfiguringacustomFormatter
CreatingAnnotationFormatterFactorytoformatonly@AmountFormatannotated
fields
ConfiguringAnnotationFormatterFactoryimplementation
13-6FileuploadsupportinSpringWebMVC
UploadingfilesusingCommonsMultipartResolver
UploadingfilesusingStandardServletMultipartResolver
13-7Summary
Chapter14–SecuringapplicationsusingSpringSecurity
14-1Introduction

14-2SecurityrequirementsoftheMyBankwebapplication
14-3SecuringMyBankwebapplicationusingSpringSecurity
Webrequestsecurityconfiguration
Authenticationconfiguration
SecuringJSPcontentusingSpringSecurity’sJSPtablibrary
Securingmethods
14-4MyBankwebapplication-securingFixedDepositDetailsinstancesusingSpring
Security’sACLmodule
Deployingandusingch14-bankapp-db-securityproject
DatabasetablestostoreACLanduserinformation
Userauthentication
Webrequestsecurity
JdbcMutableAclServiceconfiguration
Method-levelsecurityconfiguration
Domainobjectinstancesecurity
ManagingACLentriesprogrammatically
MutableAclandsecurity
14-5Summary
AppendixA–ImportinganddeployingsampleprojectsinEclipseIDE(orIntelliJ
IDEA)
A-1Settingupthedevelopmentenvironment
A-2ImportingasampleprojectintoEclipseIDE(orIntelliJIDEA)
Importingasampleproject
ConfiguringtheM2_REPOclasspathvariableintheEclipseIDE
A-3ConfiguringEclipseIDEwithTomcat7server
A-4DeployingawebprojectonTomcat7server
RunningtheTomcat7serverinembeddedmode










Preface

Howtousethisbook

Downloadsampleprojects

This book comes with many sample projects that you can download from the following Google Code

project:http://code.google.com/p/getting-started-with-spring-framework-2edition/.Youcandownloadthe

sampleprojectsasasingleZIPfileoryoucancheckoutthesampleprojectsusingSVN.Formoredetails,

refertotheaboveURL.

ImportsampleprojectsintoyourEclipseorIntelliJIDEAIDE

IfyouseeIMPORTchapter<chapter-number>/<projectname>at anypoint while reading the book,

youshouldimportthespecifiedprojectintoyourEclipseorIntelliJIDEAIDE(oranyotherIDEthatyou

areusing).ThesampleprojectsuseMaven3.xbuildtoolforbuildingtheproject;therefore,you’llfinda

pom.xmlfileinsideeachoftheprojects.Apom.xmlfileisalsoprovidedattherootofthesourcecode

distribution,whichbuildsalltheprojects.

ReferappendixAtoseethestepsrequiredforimportingandrunningthesampleprojects.

Refertocodeexamples

Each example listing specifies the sample project name (using Project label) and the location of the

sourcefile(usingSourcelocationlabel).IftheProjectandSourcelocationlabelsarenotspecified,you

canassumethatthecodeshownintheexamplelistingisnotbeingusedanywhereinthesampleprojects,

andithasbeenshownpurelytosimplifyunderstanding.

Conventionsusedinthisbook

Italicshasbeenusedforemphasizingterms

Comic Sans MS has been used for example listings, Java code, configuration details in XML and

propertiesfiles

Comic Sans MS has been used in example listings to highlight important parts of the code or

configuration

ANOTEhighlightsanimportaintpoint.



Feedbackandquestions

You can post your feedback and questions to the authors in the following Google Groups forum:

https://groups.google.com/forum/#!forum/getting-started-with-spring-framework

Abouttheauthors

AshishSarinisaSunCertifiedEnterpriseArchitectwithmorethan14yearsofexperienceinarchitecting

applications.HeistheauthorofSpringRoo1.1Cookbook(byPacktPublishing)andPortletsinAction

(byManningPublications)

JSharmaisafreelanceJavadeveloperwithextensiveexperienceindevelopingSpringapplications.

Chapter1–IntroductiontoSpringFramework

1-1Introduction

InthetraditionalJavaenterpriseapplicationdevelopmentefforts,itwasadeveloper’sresponsibilityto

createwell-structured,maintainableandeasilytestableapplications.Thedevelopersusedmyriaddesign

patternstoaddressthesenon-businessrequirementsofanapplication.Thisnotonlyledtolowdeveloper

productivity,butalsoadverselyaffectedthequalityofdevelopedapplications.

Spring Framework (or ‘Spring’ in short) is an open source application framework from SpringSource

(http://www.springsource.org) that simplifies developing Java enterprise applications. It provides the

infrastructurefordevelopingwell-structured,maintainableandeasilytestableapplications.Whenusing

Spring Framework, a developer only needs to focus on writing the business logic of the application,

resultinginimproveddeveloperproductivity.YoucanuseSpringFrameworktodevelopstandaloneJava

applications,webapplications,applets,oranyothertypeofJavaapplication.

ThischapterstartsoffwithanintroductiontoSpringFrameworkmodulesanditsbenefits.Attheheartof

SpringFrameworkisitsInversionofControl(IoC)container,whichprovidesdependencyinjection(DI)

feature.  This chapter introduces Spring’s DIfeature and IoC container, and shows how to develop a

standalone Java application using Spring. Towards the end of this chapter, we’ll look at some of the

SpringSource’sprojectsthatuseSpringFrameworkastheirfoundation.Thischapterwillsetthestagefor

theremainingchaptersthatdelvedeeperintotheSpringFramework.

NOTEInthisbook,we’lluseanexampleInternetBankingapplication,MyBank,tointroduceSpring

Frameworkfeatures.

1-2SpringFrameworkmodules

SpringFrameworkconsistsofmultiplemodulesthataregroupedbasedontheapplicationdevelopment

featurestheyaddress.ThefollowingtabledescribesthedifferentmodulegroupsinSpringFramework:

Modulegroup Description

Corecontainer

ContainsmodulesthatformthefoundationofSpringFramework.Themodulesinthisgroup

provideSpring’sDIfeatureandIoCcontainerimplementation.



AOPand

instrumentation



Contains modules that support AOP (Aspect-oriented Programming) and class

instrumentation.

DataAccess/Integration

Contains modules that simplify interaction with databases and messaging providers. This

modulegroupalsocontainsmodulesthatsupportprogrammaticanddeclarativetransaction

management,andobject/XM Lmappingimplementations,likeJAXBandCastor.

Web Containsmodulesthatsimplifydevelopingwebandportletapplications.

Test Containsasinglemodulethatsimplifiescreatingunitandintegrationtests.



TheabovetableshowsthatSpringcoverseveryaspectofenterpriseapplicationdevelopment;youcan

useSpringfordevelopingwebapplications,accessingdatabases,managingtransactions,creatingunitand

integration tests, and so on. The Spring Framework modules are designed in such a way that you only

needtoincludethemodulesthatyourapplicationneeds.Forinstance,touseSpring’sDIfeatureinyour

application,youonlyneedtoincludethemodulesgroupedunderCorecontainer.Asyouprogressthrough

thisbook,you’llfinddetailsofsomeofthemodulesthatarepartofSpring,andexamplesthatshowhow

theyareusedindevelopingapplications.

Thefollowingfigureshowstheinter-dependenciesofdifferentmodulesofSpring:



Figure1-1Springmodulesinter-dependencies

YoucaninferfromtheabovefigurethatthemodulescontainedintheCorecontainergrouparecentralto

theSpringFramework,andothermodulesdependonit.Equallyimportantarethemodulescontainedin

theAOPandinstrumentationgroupbecausetheyprovideAOPfeaturestoothermodulesintheSpring

Framework.

Now,thatyouhavesomebasicideaabouttheareasofapplicationdevelopmentcoveredbySpring,let’s

lookattheSpringIoCcontainer.

1-3SpringIoCcontainer

AJavaapplicationconsistsofobjectsthatinteractwitheachothertoprovideapplicationbehavior.The

objectswithwhichanobjectinteractsarereferredtoasitsdependencies.Forinstance,ifanobjectX

interactswithobjectsYandZ,thenYandZaredependenciesofobjectX.DIisadesignpatterninwhich

thedependenciesofanobjectaretypicallyspecifiedasargumentstoitsconstructorandsettermethods.

And,thesedependenciesareinjectedintotheobjectwhenit’screated.

In a Spring application, Spring IoC container (also referred to as Spring container) is responsible for

creating application objects and injecting their dependencies. The application objects that the Spring

containercreatesandmanagesarereferredasbeans.AstheSpringcontainerisresponsibleforputting

togetherapplicationobjects,youdon’tneedtoimplementdesignpatterns,likeFactory,ServiceLocator,

andsoon,tocomposeyourapplication.DIisalsoreferredtoasInversionofControl(IoC)becausethe

responsibilityofcreatingandinjectingdependenciesisnotwiththeapplicationobjectbutwiththeSpring

container.

Let’ssaythattheMyBankapplication(whichisthenameofoursampleapplication)containstwoobjects,

FixedDepositController and FixedDepositService. The following example listing shows that the

FixedDepositControllerobjectdependsonFixedDepositServiceobject:

Examplelisting1-1:FixedDepositControllerclass

publicclassFixedDepositController{

privateFixedDepositServicefixedDepositService;



publicFixedDepositController(){

fixedDepositService=newFixedDepositService();

}



publicbooleansubmit(){

//--savethefixeddepositdetails

fixedDepositService.save(.....);

}

}

In the above example listing, FixedDepositController’s constructor creates an instance of

FixedDepositService which is later used in FixedDepositController’s submit method. As

FixedDepositController interacts with FixedDepositService, FixedDepositService represents a

dependencyofFixedDepositController.

To configure FixedDepositController as a Spring bean, you first need to modify the

FixedDepositControllerclassofexamplelisting1-1suchthatitacceptsFixedDepositServicedependency

as a constructor argument or as a setter method argument. The following example listing shows the

modifiedFixedDepositControllerclass:

Example listing 1-2: FixedDepositController class – FixedDepositService is passed as a constructor

argument

publicclassFixedDepositController{

privateFixedDepositServicefixedDepositService;



publicFixedDepositController(FixedDepositServicefixedDepositService){

this.fixedDepositService=fixedDepositService;

}



publicbooleansubmit(){

//--savethefixeddepositdetails

fixedDepositService.save(.....);

}

}

TheaboveexamplelistingshowsthattheFixedDepositServiceinstanceisnowpassedasaconstructor

argumenttotheFixedDepositControllerinstance.Now,theFixedDepositServiceclasscanbeconfigured

as a Spring bean. Notice that the FixedDepositController class doesn’t implement or extend from any

Springinterfaceorclass.

Foragivenapplication,informationaboutapplicationobjectsandtheirdependenciesisspecifiedusing

configurationmetadata. Spring IoC container reads application’s configuration metadata to instantiate

applicationobjectsandinjecttheirdependencies.Thefollowingexamplelistingshowstheconfiguration

metadata(inXMLformat)foranapplicationthatconsistsofMyControllerandMyServiceclasses:

Examplelisting1-3:Configurationmetadata

<beans.....>

<beanid="myController"class="sample.spring.controller.MyController">

<constructor-argindex="0"ref="myService"/>

</bean>



<beanid="myService"class="sample.spring.service.MyService"/>

</beans>

Intheaboveexamplelisting,each<bean>elementdefinesanapplicationobjectthatismanagedbythe

Springcontainer,andthe<constructor-arg>elementspecifiesthataninstanceofMyServiceispassedas

anargumenttoMyController’sconstructor.The<bean>elementisdiscussedindetaillaterinthischapter,

andthe<constructor-arg>elementisdiscussedinchapter2.

Spring container reads the configuration metadata (like the one shown in example listing 1-3) of an

application and creates the application objects defined by <bean> elements and injects their

dependencies. Spring container makes use of Java Reflection API

(http://docs.oracle.com/javase/tutorial/reflect/index.html) to create application objects and inject their

dependencies.ThefollowingfiguresummarizeshowtheSpringcontainerworks:

Figure 1-2 Spring container reads application’s configuration metadata and creates a fully-configured

application

TheconfigurationmetadatacanbesuppliedtotheSpringcontainerviaXML(asshowninexamplelisting

1-3),Javaannotations(referchapter6)andalsothroughtheJavacode(referchapter6).

AstheSpringcontainerisresponsibleforcreatingandmanagingapplicationobjects,enterpriseservices

(like transaction management, security, remote access, and so on) can be transparently applied to the

objectsbytheSpringcontainer.TheabilityoftheSpringcontainertoenhancetheapplicationobjectswith

additional functionality makes it possible for you to model your application objects as simple Java

objects(alsoreferredtoasPOJOsorPlainOldJavaObjects).JavaclassescorrespondingtoPOJOs

are referred to as POJO classes, which are nothing but Java classes that don’t implement or extend

framework-specificinterfacesorclasses.Theenterpriseservices,liketransactionmanagement,security,

remoteaccess,andsoon,requiredbythesePOJOsaretransparentlyprovidedbytheSpringcontainer.

Now,thatweknowhowSpringcontainerworks,let’slookatsomeexamplesthatdemonstratebenefitsof

developingapplicationsusingSpring.

1-4BenefitsofusingSpringFramework

Intheprevioussection,wediscussedthefollowingbenefitsofusingSpring:

§Springsimplifiescomposing Javaapplications bytakingcare ofcreating applicationobjects and

injectingtheirdependencies

§SpringpromotesdevelopingapplicationsasPOJOs

SpringalsosimplifiesinteractionwithJMSproviders,JNDI,MBeanservers,emailservers,databases,

andsoon,byprovidingalayerofabstractionthattakescareoftheboilerplatecode.

Let’s take a quick look at a few examples to better understand the benefits of developing applications

usingSpring.

Consistentapproachtomanaginglocalandglobaltransactions

If you are using Spring for developing transactional applications, you can use Spring’s declarative

transactionmanagementsupporttomanagetransactions.

ThefollowingexamplelistingshowstheFixedDepositServiceclassofMyBankapplication:

Examplelisting1-4–FixedDepositServiceclass

publicclassFixedDepositService{

publicFixedDepositDetailsgetFixedDepositDetails(.....){.....}

publicbooleancreateFixedDeposit(FixedDepositDetailsfixedDepositDetails){.....}

}

TheFixedDepositService class is a POJO class that defines methods to create and retrieve details of

fixeddeposits.Thefollowingfigureshowstheformforcreatinganewfixeddeposit:



Figure1-3HTMLformforcreatinganewfixeddeposit



Acustomerentersthefixeddepositamount,tenureandemailidinformationintheaboveformandclicks

theSave button to create a new fixed deposit. The FixedDepositService’s createFixedDeposit method

(referexamplelisting1-1)isinvokedtocreatethefixeddeposit.ThecreateFixedDepositmethoddebits

theamountenteredbythecustomerfromhisbankaccount,andcreatesafixeddepositofthesameamount.

Let’ssaythatinformationaboutthebankbalanceofcustomersisstoredinBANK_ACCOUNT_DETAILS

databasetable,andthefixeddepositdetailsarestoredinFIXED_DEPOSIT_DETAILSdatabasetable.If

a customer creates a fixed deposit of amount x, amount x is subtracted from the

BANK_ACCOUNT_DETAILStable,andanewrecordisinsertedinFIXED_DEPOSIT_DETAILStable

toreflectthenewlycreatedfixeddeposit.IfBANK_ACCOUNT_DETAILStableisnotupdatedoranew

recordisnotinsertedinFIXED_DEPOSIT_DETAILStable,it’llleavethesysteminaninconsistentstate.

ThismeansthecreateFixedDepositmethodmustbeexecutedwithinatransaction.

The database used by the MyBank application represents a transactional resource. In the traditional

approachtoperforma setof databasemodificationsasasingleunitof work,you’llfirstdisableauto-

commit mode of JDBC connection, then execute SQL statements, and finally commit (or rollback) the

transaction. The following example listing shows how to manage database transactions in the

createFixedDepositmethodusingthetraditionalapproach:

Examplelisting1-5–ProgrammaticallymanagingdatabasetransactionusingJDBCConnectionobject

importjava.sql.Connection;

importjava.sql.SQLException;



publicclassFixedDepositService{

publicFixedDepositDetailsgetFixedDepositDetails(.....){.....}



publicbooleancreateFixedDeposit(FixedDepositDetailsfixedDepositDetails){

Connectioncon=.....;

try{

con.setAutoCommit(false);

//--executeSQLstatementsthatmodifydatabasetables

con.commit();

}catch(SQLExceptionsqle){

if(con!=null){

con.rollback();

}

}

.....

}

}

TheaboveexamplelistingshowsthatthecreateFixedDepositmethodprogrammaticallymanagesdatabase

transactionusingJDBCConnectionobject.Thisapproachissuitableforapplicationscenariosinwhicha

singledatabaseisinvolved.Transactionsthatareresource-specific,likethetransactionassociatedwitha

JDBCConnection,arereferredtoaslocaltransactions.

When multiple transactional resources are involved, JTA (Java Transaction API) is used for managing

transactions.Forinstance,ifyouwanttosendaJMSmessagetoamessagingmiddleware(atransactional

resource)andupdateadatabase(anothertransactionalresource)inthesametransaction,youmustusea

JTA transaction manager to manage transactions. JTA transactions are also referred to as global (or

distributed)transactions.TouseJTA,youfetchUserTransactionobject(whichispartofJTAAPI)from

JNDIandprogrammaticallystartandcommit(orrollback)transactions.

As you can see, you can either useJDBC Connection (for local transactions) or UserTransaction (for

globaltransactions)objecttoprogrammaticallymanage transactions.Itisimportanttonotethatalocal

transaction cannot run within a global transaction. This means that if you want database updates in

createFixedDepositmethod(referexamplelisting1-5)tobepartofaJTAtransaction,youneedtomodify

thecreateFixedDepositmethodtousetheUserTransactionobjectfortransactionmanagement.

Spring simplifies transaction management by providing a layer of abstraction that gives a consistent

approach to managing both local and global transactions.  This means that if you write the

createFixedDepositmethod(referexamplelisting1-5)usingSpring’stransactionabstraction,youdon’t

needtomodifythemethodwhenyouswitchfromlocaltoglobaltransactionmanagement,orviceversa.

Spring’stransactionabstractionisexplainedinchapter7.

Declarativetransactionmanagement

Springgivesyoutheoptiontousedeclarativetransactionmanagement.Youcanannotateamethodwith

Spring’s@TransactionalannotationandletSpringhandletransactions,asshownhere:

Examplelisting1-6–@Transactionalannotationusage

importorg.springframework.transaction.annotation.Transactional;



publicclassFixedDepositService{

publicFixedDepositDetailsgetFixedDepositDetails(.....){.....}





@Transactional

publicbooleancreateFixedDeposit(FixedDepositDetailsfixedDepositDetails){.....}

}

TheaboveexamplelistingshowsthattheFixedDepositServiceclassdoesn’timplementorextendfrom

any Spring-specific interface or class to use Spring’s transaction management facility. The Spring

Framework transparently provides transaction management feature to @Transactional annotated

createFixedDeposit method. This shows that Spring is a non-invasive framework because it doesn’t

require your application objects to be dependent upon Spring-specific classes or interfaces. Also, you

don’tneedtodirectlyworkwithtransactionmanagementAPIstomanagetransactions.

Security

Security is an important aspect of any Java application. Spring Security

(http://static.springsource.org/spring-security/site/) is a SpringSource’s project that is built on top of

SpringFramework.SpringSecurityprovidesauthenticationandauthorizationfeaturesthatyoucanusefor

securingJavaapplications.

Let’s say that the following 3 user roles have been identified for the MyBank application:

LOAN_CUSTOMER, SAVINGS_ACCOUNT_CUSTOMER and APPLICATION_ADMIN. A customer

mustbeassociatedwiththeSAVINGS_ACCOUNT_CUSTOMERortheAPPLICATION_ADMINroleto

invokethecreateFixedDepositmethod of FixedDepositService class (refer example listing 1-6). Using

Spring Security youcan easily address this requirementby annotating createFixedDeposit method with

SpringSecurity’s@Securedannotation,asshowninthefollowingexamplelisting:

Examplelisting1-7–SecuredcreateFixedDepositmethod

importorg.springframework.transaction.annotation.Transactional;

importorg.springframework.security.access.annotation.Secured;



publicclassFixedDepositService{

publicFixedDepositDetailsgetFixedDepositDetails(.....){.....}



@Transactional

@Secured({"SAVINGS_ACCOUNT_CUSTOMER","APPLICATION_ADMIN"})

publicbooleancreateFixedDeposit(FixedDepositDetailsfixedDepositDetails){.....}

}

If you annotate a method with Spring Security’s @Secured annotation, security feature is transparently

applied to the method by the Spring Security framework. The above example listing shows that for

implementingmethod-levelsecurityyoudon’tneedtoextendorimplementanySpring-specificclassesor

interfaces.Also,youdon’tneedtowritesecurity-relatedcodeinyourbusinessmethods.

SpringSecurityframeworkisdiscussedindetailinchapter14.

JMX(JavaManagementExtensions)

Spring’sJMXsupportsimplifiesincorporatingJMXtechnologyinyourapplications.

Let’ssaythatthefixeddepositfacilityofMyBankapplicationshouldonlybeavailabletocustomersfrom

9:00 AM to 6:00 PM everyday. To address this requirement, a variable is added to the

FixedDepositServiceclass,whichactsasaflagindicatingwhetherthefixeddepositserviceisactiveor

inactive.ThefollowingexamplelistingshowstheFixedDepositServiceclassthatusessuchaflag:

Examplelisting1-8–FixedDepositServicewithactivevariable

publicclassFixedDepositService{

privatebooleanactive;



publicFixedDepositDetailsgetFixedDepositDetails(.....){

if(active){.....}

}

publicbooleancreateFixedDeposit(FixedDepositDetailsfixedDepositDetails){

if(active){.....}

}

publicvoidactivateService(){

active=true;

}

publicvoiddeactivateService(){

active=false;

}

}

TheaboveexamplelistingshowsthatavariablenamedactiveisaddedtotheFixedDepositServiceclass.

If the value of the active variable is true, the getFixedDepositDetails and createFixedDeposit methods

work as expected. If the value of the active variable is false, the getFixedDepositDetails and

createFixedDeposit methods throw an exception indicating that the fixed deposit service is currently

inactive.TheactivateServiceanddeactivateServicemethodssetthevalueofactivevariabletotrueand

false,respectively.

Now, who calls the activateService and deactivateService methods? Let’s say a separate scheduler

application, Bank App Scheduler, runs at 9:00 AM and 6:00 PM to execute activateService and

deactivateService methods, respectively. The Bank App Scheduler application uses JMX (Java

ManagementExtensions)APItoremotelyinteractwithFixedDepositServiceinstance.

NOTE Refer to the following article to learn more about JMX:

http://docs.oracle.com/javase/tutorial/jmx/index.html.

AsBankAppSchedulerusesJMXtochangethevalueoftheactivevariableoftheFixedDepositService

instance,youneedtoregistertheFixedDepositServiceinstanceasamanagedbean(orMBean)withan

MBean server, and expose FixedDepositService’s activateService and deactivateService methods as

JMXoperations.InSpring,youregisterinstancesofaclasswiththeMBeanserverbyannotatingtheclass

withSpring’s @ManagedResource annotation, and expose the methods of the class as JMX operations

usingSpring’s@ManagedOperationannotation.

Thefollowingexamplelistingshowsusageof@ManagedResourceand@ManagedOperationannotations

to register instances of the FixedDepositService class with the MBean server, and to expose its

activateServiceanddeactivateServicemethodsasJMXoperations:

Examplelisting1-9–FixedDepositServiceclassthatusesSpring’sJMXsupport

importorg.springframework.jmx.export.annotation.ManagedOperation;

importorg.springframework.jmx.export.annotation.ManagedResource;



@ManagedResource(objectName="fixed_deposit_service:name=FixedDepositService")

publicclassFixedDepositService{

privatebooleanactive;



publicFixedDepositDetailsgetFixedDepositDetails(.....){

if(active){.....}

}

publicbooleancreateFixedDeposit(FixedDepositDetailsfixedDepositDetails){

if(active){.....}

}



@ManagedOperation

publicvoidactivateService(){

active=true;

}



@ManagedOperation

publicvoiddeactivateService(){

active=false;

}

}

The above example listing shows that the FixedDepositService class doesn’t directly use JMX API to

JMS(JavaMessageService)

Spring’sJMSsupportsimplifiessendingandreceivingmessagesfromJMSproviders.

InMyBankapplication,whenacustomersubmitsarequesttoreceivedetailsoftheirfixeddepositsvia

email, the FixedDepositService sends the request details to a JMS messaging middleware (like

ActiveMQ).Therequestislaterprocessedbyamessagelistener.SpringsimplifiesinteractionwithJMS

providers by providing a layer of abstraction. The following example listing shows how

FixedDepositServiceclasssendsrequestdetailstoaJMSproviderusingSpring’sJmsTemplate:

Examplelisting1-10–FixedDepositServicethatsendsJMSmessages

importorg.springframework.beans.factory.annotation.Autowired;

importorg.springframework.jms.core.JmsTemplate;



publicclassFixedDepositService{

@Autowired

privatetransientJmsTemplatejmsTemplate;

.....

publicbooleansubmitRequest(Requestrequest){

jmsTemplate.convertAndSend(request);

}

}

TheaboveexamplelistingshowsthattheFixedDepositServicedefinesavariableoftypeJmsTemplate,

andisannotatedwithSpring’s@Autowiredannotation.Fornow,youcanassumethatthe@Autowired

annotationprovidesaccesstoaJmsTemplateinstance.TheJmsTemplateinstanceknowsabouttheJMS

destinationtowhichtheJMSmessageistobesent.HowtheJmsTemplateisconfiguredisdescribedin

detail in chapter 8. The FixedDepositService’s submitRequest method invokes JmsTemplate’s

convertAndSend method to send request details (represented by Request argument of submitRequest

method)asaJMSmessagetotheJMSprovider.

Onceagain,theaboveexamplelistingshowsthatifyouareusingSpringFrameworktosendmessagesto

JMSproviders,thenyoudon’tneedtodirectlydealwithJMSAPI.

Caching

Spring’scacheabstractionprovidesaconsistentapproachtousecachinginyourapplication.

It’scommontousecachingsolutionstoimprovetheperformanceofanapplication.MyBankapplication

usesacachingproducttoimprovetheperformanceofreadoperationsforfixeddepositdetails.Spring

Frameworksimplifiesinteractingwithdifferentcachingsolutionsbyabstractingcaching-relatedlogic.

ThefollowingexamplelistingshowsthattheFixedDepositService’sgetFixedDepositDetailsmethoduses

Spring’scacheabstractionfeaturetocachefixeddepositdetails:

Examplelisting1-11–FixedDepositServicethatcachesfixeddepositdetails

importorg.springframework.cache.annotation.Cacheable;



publicclassFixedDepositService{



@Cacheable("FixedDeposits")

publicFixedDepositDetailsgetFixedDepositDetails(.....){.....}



publicbooleancreateFixedDeposit(FixedDepositDetailsfixedDepositDetails){.....}

}

In the above example listing, Spring’s @Cacheable annotation indicates that the fixed deposit details

returned by the getFixedDepositDetails method are cached. If the getFixedDepositDetails method is

invoked with the same argument value(s), the getFixedDepositDetails method is not executed, and the

fixeddepositdetailsarereturnedfromthecache.ThisshowsthatifyouareusingSpringFrameworkyou

don’tneedtowritecaching-relatedlogicinyourclasses.Spring’scacheabstractionisexplainedindetail

inchapter8.

In this section, we saw that Spring Framework simplifies developing enterprise applications by

transparentlyprovidingservicestoPOJOs,thereby shieldingdevelopersfrom lowerlevelAPIdetails.

Spring also provides easy integration with standard frameworks, like Hibernate, iBATIS, Quartz, JSF,

Struts,EJB,andsoon,whichmakesSpringanidealchoiceforenterpriseapplicationdevelopment.

Now,thatwehavelookedatsomeofthebenefitsofusingSpringFramework,let’stakealookathowto

developasimpleSpringapplication.

1-5AsimpleSpringapplication

Inthissection,we’lllookatasimpleSpringapplicationthatusesSpring’sDIfeature.TouseSpring’sDI

featureinanapplication,followthesesteps:

1.identifyapplicationobjectsandtheirdependencies

2.createPOJOclassescorrespondingtotheapplicationobjectsidentifiedinstep1

3.createconfigurationmetadatathatdepictsapplicationobjectsandtheirdependencies

4.createaninstanceofSpringIoCcontainerandpasstheconfigurationmetadatatoit

5.accessapplicationobjectsfromtheSpringIoCcontainerinstance

Let’snowlookatabovementionedstepsinthecontextofMyBankapplication.

Identifyingapplicationobjectsandtheirdependencies

WediscussedearlierthattheMyBankapplicationshowsaformforcreatingafixeddeposit(referfigure

1-3) to its users for creating a fixed deposit. The following sequence diagram shows the application

objects(andtheirinteraction)thatcomeintopicturewhentheusersubmitstheform:

Figure1-4MyBank’sapplicationobjectsandtheirdependencies

In the above sequence diagram, FixedDepositController represents a web controller that receives the

requestwhentheformissubmitted.ThefixeddepositdetailsarecontainedintheFixedDepositDetails

object.TheFixedDepositController invokes the createFixedDeposit method of FixedDepositService (a

servicelayerobject).Then,FixedDepositServiceinvokesFixedDepositDaoobject(adataaccessobject)

to save the fixed deposit details in the application’s data store. So, we can interpret from the above

diagram that FixedDepositService is a dependency of FixedDepositController object, and

FixedDepositDaoisadependencyofFixedDepositServiceobject.

IMPORT chapter 1/ch01-bankapp-xml (This project shows a simple Spring application that uses

Spring’s DI feature. To run the application, execute the main method of the MyBankApp class of this

project)

CreatingPOJOclassescorrespondingtoidentifiedapplicationobjects

Onceyouhaveidentifiedapplicationobjects,thenextstep istocreatePOJOclassescorresponding to

these application objects. POJO classes corresponding to the FixedDepositController,

FixedDepositService and FixedDepositDao application objects are available in ch01-bankapp-xml

project.Thech01-bankapp-xmlprojectrepresentsasimplifiedversionofMyBankapplicationthatuses

Spring’sDIfeature.Youshouldimportthech01-bankapp-xmlprojectintoyourIDEasintheremaining

stepswe’llbelookingatthefilescontainedinthisproject.

In section 1-3 we discussed that a dependency is passed to an application object as a constructor

argument or as a setter method argument. The following code listing shows that an instance of

FixedDepositService(adependencyofFixedDepositController)ispassedasasettermethodargumentto

theFixedDepositControllerobject:

Examplelisting1-12–FixedDepositControllerclass

Project–ch01-bankapp-xml

Sourcelocation-src/main/java/sample/spring/chapter01/bankapp



packagesample.spring.chapter01.bankapp;

.....

publicclassFixedDepositController{

.....

privateFixedDepositServicefixedDepositService;

.....

publicvoidsetFixedDepositService(FixedDepositServicefixedDepositService){

logger.info("SettingfixedDepositServiceproperty");

this.fixedDepositService=fixedDepositService;

}

.....

publicvoidsubmit(){

fixedDepositService.createFixedDeposit(newFixedDepositDetails(1,10000,

365,"someemail@something.com"));

}

.....

}

In the above example listing, FixedDepositService dependency is passed to FixedDepositController

throughsetFixedDepositServicemethod.We’llsoonseethatthesetFixedDepositServicesettermethodis

invokedbySpring.

NOTE If you look at the FixedDepositController,FixedDepositService and FixedDepositDao classes,

you’ll notice that none of these classes implement any Spring-specific interface or extend from any

Spring-specificclass.

Let’s now look at how application objects and their dependencies are specified in the configuration

metadata.

Creatingtheconfigurationmetadata

We saw in section 1-3 that the configuration metadata specifies application objects and their

dependencies, which is read by the Spring container to instantiate application objects and inject their

dependencies.Inthissection,we’llfirstlookatwhatotherinformationiscontainedintheconfiguration

metadata,followedbyanin-depthlookathowconfigurationmetadataisspecifiedinXMLformat.

The configuration metadata specifies information about the enterprise services (like transaction

management,securityandremoteaccess)thatarerequiredbytheapplication.Forinstance,ifyouwant

Spring to manage transactions, you need to configure an implementation of Spring’s

PlatformTransactionManager interface in the configuration metadata. The PlatformTransactionManager

implementation is responsible for managing transactions (refer chapter 7 to know more about Spring’s

transactionmanagementfeature).

Ifyourapplicationinteractswithmessagingmiddlewares(likeActiveMQ),databases(likeMySQL),e-

mailservers,andsoon,thenSpring-specificobjectsthatsimplifyinteractingwiththeseexternalsystems

arealsodefinedintheconfigurationmetadata.Forinstance,ifyourapplicationsendsorreceivesJMS

messages from ActiveMQ, then you can configure Spring’s JmsTemplate class in the configuration

metadata to simplify interaction with ActiveMQ. We saw in example listing 1-10 that if you use

JmsTemplateforsendingmessagestoaJMSprovider,thenyoudon’tneedtodealwithlower-levelJMS

API(referchapter8toknowmoreaboutSpring’ssupportforinteractingwithJMSproviders).

YoucansupplytheconfigurationmetadatatotheSpringcontainerviaanXMLfileorthroughannotations

inPOJOclasses.StartingwithSpring3.0,youcanalsosupplytheconfigurationmetadatatotheSpring

containerthroughJavaclassesannotatedwithSpring’s@Configurationannotation.Inthissection,we’ll

seehow configurationmetadata is specifiedinXMLformat.In chapter 6,we’ll see how configuration

metadataissuppliedviaannotationsinPOJOclassesandthrough@ConfigurationannotatedJavaclasses.

You provide the configuration metadata for an application in XML format by creating an application

contextXMLfilethatcontainsinformationabouttheapplicationobjectsandtheirdependencies.Example

listing 1-3 showed how an application context XML file looks like. The following XML shows the

application context XML file of MyBank application that consists of FixedDepositController,

FixedDepositService and FixedDepositDao objects (refer figure 1-4 to see how these objects interact

witheachother):

Examplelisting1-13–applicationContext.xml-MyBank’sapplicationcontextXMLfile

Project–ch01-bankapp-xml

Sourcelocation-src/main/resources/META-INF/spring



<?xmlversion="1.0"encoding="UTF-8"standalone="no"?>

<beansxmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-4.0.xsd">



<beanid="controller"

class="sample.spring.chapter01.bankapp.FixedDepositController">

<propertyname="fixedDepositService"ref="service"/>

</bean>



<beanid="service"class="sample.spring.chapter01.bankapp.FixedDepositService">

<propertyname="fixedDepositDao"ref="dao"/>

</bean>



<beanid="dao"class="sample.spring.chapter01.bankapp.FixedDepositDao"/>

</beans>



ThefollowingaretheimportantpointstonoteabouttheapplicationcontextXMLfileshownabove:

·The<beans>elementistherootelementoftheapplicationcontextXMLfile,andisdefinedin

spring-beans-4.0.xsdschema(alsoreferredtoasSpring’sbeansschema).Thespring-beans-4.0.xsd

schema is contained in spring-beans-4.0.0.RELEASE.jar JAR file that comes with the Spring

Frameworkdistribution.

·Each<bean>elementconfiguresanapplicationobjectthatismanagedbytheSpringcontainer.In

SpringFramework’sterminology,a<bean>elementrepresentsabeandefinition.Theobjectthat

theSpringcontainercreatesbasedonthebeandefinitionisreferredtoasabean.Theidattribute

specifiesauniquenameforthebean,andtheclassattributespecifiesthefully-qualifiedclassname

ofthebean.Youcanalsousethenameattributeof<bean>elementtospecifyaliasesforthebean.

InMyBankapplication,theapplicationobjectsareFixedDepositController, FixedDepositService

andFixedDepositDao;therefore,wehave3<bean>elements-oneforeachapplicationobject.As

application objects configured by <bean> elements are managed by the Spring container, the

responsibility for creating them and injecting their dependencies is with the Spring container.

Insteadofdirectlycreatinginstancesofapplicationobjectsdefinedby<bean>elements,youshould

obtainthemfromtheSpringcontainer.Laterinthissection,we’lllookathowtoobtainapplication

objectsmanagedbySpringcontainer.

·        No<bean>element is defined corresponding to the FixedDepositDetails domain object of

MyBank application. This is because domain objects are not typically managed by the Spring

container;theyarecreatedbytheORMframework(likeHibernate)usedbytheapplication,oryou

createthemprogrammaticallyusingthenewoperator.

·        The <property> element specifies a dependency (or a configuration property) of the bean

configuredbythe<bean>element.The<property>elementcorrespondstoaJavaBean-stylesetter

method in the bean class which is invoked by the Spring container to set a dependency (or a

configurationproperty)ofthebean.

Let’snowlookathowdependenciesareinjectedviasettermethods.

Injectingdependenciesviasettermethods

To understand how dependencies are injected via setter methods defined in the bean class, let’s once

againlookattheFixedDepositControllerclassofMyBankapplication:

Examplelisting1-14–FixedDepositControllerclass

Project–ch01-bankapp-xml

Sourcelocation-src/main/java/sample/spring/chapter01/bankapp



packagesample.spring.chapter01.bankapp;



importorg.apache.log4j.Logger;



publicclassFixedDepositController{

privatestaticLoggerlogger=Logger.getLogger(FixedDepositController.class);



privateFixedDepositServicefixedDepositService;



publicFixedDepositController(){

logger.info("initializing");

}



publicvoidsetFixedDepositService(FixedDepositServicefixedDepositService){

logger.info("SettingfixedDepositServiceproperty");

this.fixedDepositService=fixedDepositService;

}

.....

}

The above example listing shows that the FixedDepositController class declares an instance variable

namedfixedDepositServiceoftypeFixedDepositService.ThefixedDepositServicevariableissetbythe

setFixedDepositServicemethod-aJavaBean-stylesettermethodforfixedDepositServicevariable.This

isanexampleofsetter-basedDI,whereinasettermethodsatisfiesadependency.

The following figure describes the bean definition for the FixedDepositController class in the

applicationContext.xmlfile(referexamplelisting1-13):

Figure1-5Definingdependenciesusing<property>elements

The above bean definition shows that the FixedDepositController bean defines its dependence on

FixedDepositServicebeanvia<property>element.The<property>element’snameattributecorresponds

totheJavaBean-stylesettermethodinthebeanclassthatisinvokedbytheSpringcontaineratthetimeof

beancreation.The<property>element’srefattributeidentifiestheSpringbeanwhoseinstanceneedsto

becreatedandpassedtotheJavaBean-stylesettermethod.Thevalueofrefattributemustmatchtheid

attribute’s value (or one of the names specified by the name attribute) of a <bean> element in the

configurationmetadata.

Infigure1-5,thevalueof<property>element’snameattributeisfixedDepositService,whichmeansthat

the <property> element corresponds to the setFixedDepositService setter method of

FixedDepositController class (refer example listing 1-14). As the value of <property> element’s ref

attribute is service, the <property> element refers to the <bean> element whose id attribute’s value is

service.Now,the<bean>elementwhoseidattribute’svalueisserviceistheFixedDepositServicebean

(refer example listing 1-13). Spring container creates an instance of FixedDepositService class (a

dependency), and invokes the setFixedDepositService method (a JavaBean-style setter method for

fixedDepositService variable) of FixedDepositController (a dependent object), passing the

FixedDepositServiceinstance.

InthecontextofFixedDepositControllerapplicationobject,thefollowingfiguresummarizesthepurpose

ofnameandrefattributesof<property>element:

Figure 1-6 <property> element’s name attribute corresponds to a JavaBean-style setter method that

satisfiesabeandependency,andrefattributereferstoanotherbean.

The above figure shows that fixedDepositService value of name attribute corresponds to the

setFixedDepositServicemethodofFixedDepositControllerclass,andservicevalueofrefattributerefers

tothebeanwhoseidisservice.

NOTEItisfairlycommontorefertoabeandefinitionbyitsname(whichisidattribute’svalue)ortype

(whichisclassattribute’svalue)ortheinterfaceimplementedbythebeanclass.Forinstance,youcan

refer to ‘FixedDepositController bean’ as ‘controller bean’. And, if the FixedDepositController class

implements FixedDepositControllerIntf interface, you can refer to ‘FixedDepositController bean’ as

‘FixedDepositControllerIntfbean’.

ThefollowingdiagramsummarizeshowtheSpringcontainercreatesbeansandinjectstheirdependencies

basedontheconfigurationmetadatasuppliedbytheapplicationContext.xmlfile(referexamplelisting1-

13)ofMyBankapplication:

Figure1-7-ThesequenceinwhichSpringIoCcontainercreatesbeansandinjectstheirdependencies.

The above figure shows the sequence of steps followed by the Spring IoC container to create

FixedDepositController, FixedDepositService and FixedDepositDao beans and inject their

dependencies.  Before attempting to create beans, the Spring container reads and validates the

configuration metadata supplied by the applicationContext.xml file. The order in which the beans are

created by the Spring container depends on the order in which they are defined in the

applicationContext.xml file.  Spring container ensures that the dependencies of a bean are completely

configured before the setter method is invoked. For example, the FixedDepositController bean is

dependentonFixedDepositServicebean;therefore,SpringcontainerconfigurestheFixedDepositService

beanbeforeinvokingthesetFixedDepositServicemethodofFixedDepositControllerbean.

The bean definitions that we have seen so far, instruct Spring container to create bean instances by

invokingtheno-argumentconstructorofthebeanclass,andinjectdependenciesusingsetter-basedDI.In

chapter 2, we’ll look at bean definitions that instruct Spring container to create a bean instance via a

factorymethod defined in a class. Also, we’ll look at how to inject dependencies through constructor

arguments(referredtoasconstructor-basedDI),throughargumentstothefactorymethodthatcreatesthe

beaninstance,andbyusingsetter-basedDIonthebeaninstancereturnedbythefactorymethod.

Let’snowlookathowtocreateaninstanceofSpringcontainerandpassconfigurationmetadatatoit.

CreatinganinstanceofSpringcontainer

Spring’s ApplicationContext object represents an instance of Spring container. Spring provides a few

built-in implementations of ApplicationContext interface, like ClassPathXmlApplicationContext,

FileSystemXmlApplicationContext, XmlWebApplicationContext, XmlPortletApplicationContext, and so

on. The choice of the ApplicationContext implementation depends on how you have defined the

configuration metadata (using XML, annotations or Java code), and the type of your application

(standalone, web or portlet application). For instance, ClassPathXmlApplicationContext and

FileSystemXmlApplicationContext classes are suitable for standalone applications in which

configuration metadata is supplied in XML format, XmlWebApplicationContext is suitable for web

applications in which the configuration metadata is supplied in XML format,

AnnotationConfigWebApplicationContext is suitable for web applications in which configuration

metadataissuppliedthroughJavacode,andsoon.

As MyBank application represents a standalone application, we can use either

ClassPathXmlApplicationContext or FileSystemXmlApplicationContext class to create an instance of

Spring container. You should note that the ClassPathXmlApplicationContext class loads an application

contextXMLfilefromthespecifiedclasspathlocation,andtheFileSystemXmlApplicationContextclass

loadsanapplicationcontextXMLfilefromthespecifiedlocationonthefilesystem.

The following BankApp class of MyBank application shows that an instance of Spring container is

createdusingtheClassPathXmlApplicationContextclass:

Examplelisting1-15–BankAppclass

Project–ch01-bankapp-xml

Sourcelocation-src/main/java/sample/spring/chapter01/bankapp



packagesample.spring.chapter01.bankapp;



importorg.springframework.context.ApplicationContext;

importorg.springframework.context.support.ClassPathXmlApplicationContext;



publicclassBankApp{

.....

publicstaticvoidmain(Stringargs[]){

ApplicationContextcontext=newClassPathXmlApplicationContext(

"classpath:META-INF/spring/applicationContext.xml");

.....

}

}

TheaboveexamplelistingshowstheBankApp’smainmethod,whichisresponsibleforbootstrappingthe

Springcontainer.TheclasspathlocationoftheapplicationcontextXMLfileispassedtotheconstructor

of ClassPathXmlApplicationContext class. The creation of ClassPathXmlApplicationContext instance

resultsincreationofthosebeansintheapplicationcontextXMLfilethataresingleton-scopedandsetto

bepre-instantiated.Inchapter 2,we’ll discussbean scopes, andwhatitmeanstohave beanspre- or

lazily-instantiated by Spring container. For now, you can assume that the beans defined in the

applicationContext.xml file of MyBank application are singleton-scoped and set to be pre-instantiated.

This means that the beans defined in the applicationContext.xml file are created when an instance of

ClassPathXmlApplicationContextiscreated.

Now,thatwehaveseenhowtocreateaninstanceoftheSpringcontainer,let’slookathowtoretrieve

beaninstancesfromtheSpringcontainer.

AccessbeansfromtheSpringcontainer

Theapplicationobjectsdefinedvia<bean>elementsarecreatedandmanagedbytheSpringcontainer.

You can access instances of these application objects by calling one of the getBean methods of the

ApplicationContextinterface.

The following example listing shows the main method of BankApp class that retrieves an instance of

FixedDepositControllerbeanfromtheSpringcontainerandinvokesitsmethods:

Examplelisting1-16–BankAppclass

Project–ch01-bankapp-xml

Sourcelocation-src/main/java/sample/spring/chapter01/bankapp



packagesample.spring.chapter01.bankapp;



importorg.apache.log4j.Logger;

importorg.springframework.context.ApplicationContext;

importorg.springframework.context.support.ClassPathXmlApplicationContext;



publicclassBankApp{

privatestaticLoggerlogger=Logger.getLogger(BankApp.class);



publicstaticvoidmain(Stringargs[]){

ApplicationContextcontext=newClassPathXmlApplicationContext(

"classpath:META-INF/spring/applicationContext.xml");



FixedDepositControllerfixedDepositController=

(FixedDepositController)context.getBean("controller");

logger.info("Submissionstatusoffixeddeposit:"+fixedDepositController.submit());

logger.info("Returnedfixeddepositinfo:"+fixedDepositController.get());

}

}

At first, the ApplicationContext’s getBean method is invoked to retrieve an instance of

FixedDepositController bean from the Spring container, followed by invocation of submit and get

methodsofFixedDepositControllerbean.TheargumentpassedtothegetBeanmethodisthenameofthe

beanwhoseinstanceyouwanttoretrievefromtheSpringcontainer.Thenameofthebeanpassedtothe

getBeanmethodmustbethevalueoftheidornameattributeofthebeanthatyouwanttoretrieve.Ifno

bean with the specified name is registered with the Spring container, an exception is thrown by the

getBeanmethod.

In example listing 1-16, to configure the FixedDepositController instance, we didn’t programmatically

createaninstanceofFixedDepositService and set it on the FixedDepositController instance. Also, we

didn’t create an instance of FixedDepositDao and set it on the FixedDepositService instance. This is

becausethetaskofcreatingdependencies,andinjectingthemintothethedependentobjectsishandledby

theSpringcontainer.

If you go to ch01-bankapp-xml project and execute the main method of BankApp class, you’ll see the

followingoutputontheconsole:

INFOsample.spring.chapter01.bankapp.FixedDepositController-initializing

INFOsample.spring.chapter01.bankapp.FixedDepositService-initializing

INFOsample.spring.chapter01.bankapp.FixedDepositDao-initializing

INFOsample.spring.chapter01.bankapp.FixedDepositService-SettingfixedDepositDaoproperty

INFOsample.spring.chapter01.bankapp.FixedDepositController-SettingfixedDepositServiceproperty

INFOsample.spring.chapter01.bankapp.BankApp-Submissionstatusoffixeddeposit:true

INFOsample.spring.chapter01.bankapp.BankApp-Returnedfixeddepositinfo:id:1,depositamount:10000.0,tenure:365,email:

someemail@something.com

The above output shows that Spring container creates an instance of each of the beans defined in the

applicationContext.xmlfileofMyBankapplication.Also,Springcontainerusessetter-basedDItoinject

an instance of FixedDepositService into FixedDepositController instance, and an instance of

FixedDepositDaointotheFixedDepositServiceinstance.

Let’snowlookatsomeoftheframeworksthatarebuiltontopofSpringFramework.

1-6FrameworksbuiltontopofSpring

Though there are many frameworks from SpringSource that use Spring Framework as the foundation,

we’lllook atsomeofthewidelypopular ones.Foramorecomprehensivelistofframeworks,andfor

moredetailsaboutanindividualframework,it’srecommendedthatyouvisittheSpringSourcewebsite

(www.springsource.org).

Thefollowingtableprovidesahigh-leveloverviewoftheframeworksfromSpringSourcethatarebuilt

ontopofSpringFramework:



Framework Description

SpringSecurity

Authenticationandauthorizationframeworkforenterpriseapplications.Youneedto

configure a few beans in your application context XM L file to incorporate

authenticationandauthorizationfeaturesintoyourapplication.

SpringData

Provides a consistent programming model to interact with different types of

databases.Forinstance,youcanuseittointeractwithnon-relationaldatabases,like

MongoDBorNeo4j,andyoucanalsouseitforaccessingrelationaldatabasesusing

JPA.

SpringBatch Ifyourapplicationrequiresbulkprocessing,thisframeworkisforyou.

SpringIntegration ProvidesEnterpriseApplicationIntegration(EAI)capabilitiestoapplications.

SpringSocial If your application requires interaction with social media websites, like Facebook

andTwitter,thenyou’llfindthisframeworkhighlyuseful.

SpringBlazeDS

Integration

IfyouaredevelopinganAdobeFlexbasedapplication,youcanusethisframework

toconnectFlexfrontendwithSpring-basedbusinesstier.



AstheframeworksmentionedintheabovetablearebuiltontopofSpringFramework,beforeusingany

oftheseframeworksmakesurethattheyarecompatiblewiththeSpringFrameworkversionthatyouare

using.

1-7Summary

Inthischapter,welookedatthebenefitsofusingSpringFramework.WealsolookedatasimpleSpring

applicationthatshowedhowtospecifyconfigurationmetadatainXMLformat,createtheSpringcontainer

instanceandretrievebeansfromit.Inthenextchapter,we’lllookatsomeofthefoundationconceptsof

SpringFramework.

Chapter2–SpringFrameworkbasics

2-1Introduction

Inthepreviouschapter,wesawthattheSpringcontainerinvokestheno-argumentconstructorofabean

classtocreateabeaninstance,andsetter-basedDIisusedtosetbeandependencies.Inthischapter,we’ll

goastepfurtherandlookat:

§Spring’ssupportfor‘programmingtointerfaces’designprinciple

§differentapproachestoinstantiatingSpringbeans

§constructor-basedDIforpassingbeandependenciesasconstructorarguments

§constructor-andsetter-basedDIforpassingsimpleStringvaluestobeans,and

§beanscopes

Let’s begin this chapter with looking at how Spring improves testability of applications by supporting

‘programmingtointerfaces’designprinciple.

2-2Programmingtointerfacesdesignprinciple

Insection1-5ofchapter1,wesawthatadependentPOJOclasscontainedreferencetotheconcreteclass

of the dependency. For example, the FixedDepositController class contained reference to the

FixedDepositService class, and the FixedDepositService class contained reference to the

FixedDepositDaoclass.Ifadependentclasshasdirectreferencetotheconcreteclassofthedependency,

it results in tight coupling between the classes. This means that if you want to substitute a different

implementationofthedependency,it’drequirechangingthedependentclass.

Let’snowlookatascenarioinwhichadependentclasscontainsdirectreferencetotheconcreteclassof

thedependency.

Scenario:Dependentclasscontainsreferencetotheconcreteclassofdependency

Let’s say that the FixedDepositDao class makes use of plain JDBC to interact with the database. To

simplify database interaction, you create another DAO implementation, FixedDepositHibernateDao,

whichusesHibernateORMfordatabaseinteraction.Now,toswitchfromplainJDBCtoHibernateORM

implementation,you’llneedtochangeFixedDepositServiceclasstouseFixedDepositHibernateDaoclass

insteadofFixedDepositDao,asshowninthefollowingexamplelisting:



Examplelisting2-1–FixedDepositServiceclass



publicclassFixedDepositService{

privateFixedDepositHibernateDaofixedDepositDao;



publicvoidsetFixedDepositDao(FixedDepositHibernateDaofixedDepositDao){

this.fixedDepositDao=fixedDepositDao;

}



publicFixedDepositDetailsgetFixedDepositDetails(longid){

returnfixedDepositDao.getFixedDepositDetails(id);

}



publicbooleancreateFixedDeposit(FixedDepositDetailsfixedDepositDetails){

returnfixedDepositDao.createFixedDeposit(fixedDepositDetails);

}

}

The above example listing shows that reference to FixedDepositDao class was replaced by

FixedDepositHibernateDaosothatHibernateORMcanbeusedfordatabaseinteraction.Thisshowsthat

if a dependent class refers to the concrete implementation class of the dependency, then substituting a

differentimplementationrequireschangesinthedependentclass.

Let’snowlookatascenarioinwhichadependentclasscontainsreferencetotheinterfaceimplemented

bythedependency.

Scenario:Dependentclasscontainsreferencetotheinterfaceimplementedbythe

dependency

WeknowthataJavainterfacedefinesacontracttowhichtheimplementationclassesconform.So,ifa

class depends on the interface implemented by the dependency, no change is required in the class if a

different implementation of the dependency is substituted. The application design approach in which a

class depends on the interface implemented by the dependency is referred to as ‘programming to

interfaces’.Theinterfaceimplementedbythedependencyclassisreferredtoasadependencyinterface.

Asitisagooddesignpracticeto‘programtointerfaces’thanto‘programtoclasses’,thefollowingclass

diagramshowsthatitisagooddesignifABeanclassdependsonBBeaninterfaceandnotonBBeanImpl

classthatimplementsBBeaninterface:



Figure2-1-‘Programtointerfaces’isagooddesignpracticethanto‘programtoclasses’

The following class diagram shows how FixedDepositService class can make use of ‘programming to

interfaces’designapproachtoeasilyswitchthestrategyusedfordatabaseinteraction:

Figure2-2–TheFixedDepositServicedependsonFixedDepositDaointerface,whichisimplementedby

FixedDepositJdbcDaoandFixedDepositHibernateDaoclasses.

The above figure shows that the FixedDepositService class is not directly dependent on the

FixedDepositJdbcDaoorFixedDepositHibernateDaoclass.Instead,FixedDepositServicedependsonthe

FixedDepositDao interface (the dependency interface) implemented by FixedDepositJdbcDao and

FixedDepositHibernateDao classes. Now, depending on whether you want to use plain JDBC or

Hibernate ORM framework, you supply an instance of FixedDepositJdbcDao or

FixedDepositHibernateDaototheFixedDepositServiceinstance.

As FixedDepositService depends on FixedDepositDao interface, you can support other database

interactionstrategies inthe future. Let’s say that you decidetouse iBATIS(now renamed to MyBatis)

persistence framework for database interaction. You can use iBATIS without making any changes to

FixedDepositService class by simply creating a new FixedDepositIbatisDao class that implements

FixedDepositDao interface, and supplying an instance of FixedDepositIbatisDao to the

FixedDepositServiceinstance.

Sofarwehaveseenthat‘programmingtointerfaces’designapproachresultsinloosecouplingbetweena

dependentclassanditsdependencies.Let’snowlookathowthisdesignapproachimprovestestabilityof

thedependentclasses.

Improvedtestabilityofdependentclasses

In figure 2-2, we saw that the FixedDepositService class holds reference to the FixedDepositDao

interface.FixedDepositJdbcDaoandFixedDepositHibernateDaoareconcreteimplementationclassesof

FixedDepositDaointerface.Now,tosimplifyunittestingofFixedDepositServiceclass,youcansubstitute

amockimplementationofFixedDepositDaointerfacethatdoesn’trequireadatabase.

If the FixedDepositService class had direct reference to FixedDepositJdbcDao or

FixedDepositHibernateDao class, testing FixedDepositService class would have required setting up a

databasefortestingpurposes.Thisshowsthatbyusingamockimplementationofdependencyinterface,

youcansavetheefforttosetuptheinfrastructureforunittestingyourdependentclasses.

Let’snowseehowSpringsupports‘programmingtointerfaces’designapproachinapplications.

Spring’ssupportfor‘programmingtointerfaces’designapproach

Touse‘programmingtointerfaces’designapproach inyour Springapplication,youneedtoensurethe

followingthings:

§the<bean>elementsintheconfigurationmetadataspecifytheconcreteclassesofthedependency

§thedependentbean classes refer tothedependency interface insteadof the concrete class ofthe

dependency

Let’s now look at the modified MyBank application that uses ‘programming to interfaces’ design

approach.

IMPORT chapter 2/ch02-bankapp-interfaces (This project shows how ‘programming to interfaces’

designapproachisusedincreatingSpringapplications.Toruntheapplication,executethemainmethod

oftheBankAppclassofthisproject)



MyBankapplicationthatuses‘programmingtointerfaces’designapproach

The following class diagram depicts the modified MyBank application that uses ‘programming to

interfaces’designapproach:

Figure2-3-MyBankapplicationthatuses‘programtointerfaces’designapproach

Theabovefigureshowsthatadependentclassdependsontheinterfaceimplementedbythedependency,

and not on the concrete implementation class of the dependency. For instance, the

FixedDepositControllerImpl class depends on the FixedDepositService interface, and the

FixedDepositServiceImplclassdependsontheFixedDepositDaointerface.

ThefollowingexamplelistingshowstheFixedDepositServiceImpl class based onthedesignshownin

figure2-3:

Examplelisting2-2–FixedDepositServiceclass

Project–ch02-bankapp-interfaces

Sourcelocation-src/main/java/sample/spring/chapter02/bankapp



packagesample.spring.chapter02.bankapp;



publicclassFixedDepositServiceImplimplementsFixedDepositService{

privateFixedDepositDaofixedDepositDao;

.....

publicvoidsetFixedDepositDao(FixedDepositDaofixedDepositDao){

this.fixedDepositDao=fixedDepositDao;

}



publicFixedDepositDetailsgetFixedDepositDetails(longid){

returnfixedDepositDao.getFixedDepositDetails(id);

}



publicbooleancreateFixedDeposit(FixedDepositDetailsfdd){

returnfixedDepositDao.createFixedDeposit(fdd);

}

}

The above example listing shows that the FixedDepositServiceImpl class contains reference to the

FixedDepositDao interface. The FixedDepositDao implementation that you want to inject into the

FixedDepositServiceImplinstanceisspecifiedintheapplicationcontextXMLfile.Asshowninfigure2-

3, you can inject any one of the following concrete implementations of FixedDepositDao interface:

FixedDepositIbatisDao,FixedDepositJdbcDaoandFixedDepositHibernateDao.

ThefollowingexamplelistingshowstheapplicationContext.xmlfilethat caters tothe design shown in

figure2-3:

Examplelisting2-3–applicationContext.xml-MyBank’sapplicationcontextXMLfile

Project–ch02-bankapp-interfaces

Sourcelocation-src/main/resources/META-INF/spring



<?xmlversion="1.0"encoding="UTF-8"standalone="no"?>

<beans.....>



<beanid="controller"

class="sample.spring.chapter02.bankapp.controller.FixedDepositControllerImpl">

<propertyname="fixedDepositService"ref="service"/>

</bean>



<beanid="service"class="sample.spring.chapter02.bankapp.service.FixedDepositServiceImpl">

<propertyname="fixedDepositDao"ref="dao"/>

</bean>



<beanid="dao"class="sample.spring.chapter02.bankapp.dao.FixedDepositHibernateDao"/>

</beans>

The above applicationContext.xml file shows that an instance of FixedDepositHibernateDao (an

implementation of FixedDepositDao interface) is injected into FixedDepositServiceImpl. Now, if you

decidetouseiBATISinsteadofHibernateforpersistence,thenallyouneedtodoistochangetheclass

attributeofthedaobeandefinitionintheapplicationContext.xmlfiletorefertothefully-qualifiednameof

theFixedDepositIbatisDaoclass.

Let’snowlookatdifferentwaysinwhichSpringcontainercaninstantiatebeans.

2-3DifferentapproachestoinstantiatingSpringbeans

SofarwehaveseenbeandefinitionexamplesthatinstructSpringcontainertocreatebeaninstancesby

invokingtheno-argumentconstructorofthebeanclass.Considerthefollowingbeandefinition:

<beanid=”myBean”class=”mypackage.MyBean”/>

In the above bean definition, MyBean class represents a POJO class that defines a no-argument

constructor. MyBean class doesn’t implement any Spring-specific interface or extend from any Spring-

specific class. This effectively means that the Spring container can create and manage instance of any

classthatprovidesano-argumentconstructor.

NOTE It is important to note that the Spring container can create and manage instance of any class,

irrespectiveofwhethertheclassprovidesano-argumentconstructorornot.Insection2-4,we’lllookat

beandefinitionsinwhichtheconstructorofthebeanclassacceptsoneormorearguments.

Ifyouhaveanexistingprojectthatusesfactoryclassestocreateobjectinstances,youcanstilluseSpring

containertomanageobjectscreatedbythesefactories.Let’snowlookathowSpringcontainerinvokesa

staticoraninstancefactorymethodofaclasstomanagethereturnedobjectinstance.

Instantiatingbeansviastaticfactorymethods

Infigure2-3,wesawthattheFixedDepositDaointerfaceisimplementedbyFixedDepositHibernateDao,

FixedDepositIbatisDao and FixedDepositJdbcDao classes. The following example listing shows a

FixedDepositDaoFactoryclassthatdefinesastaticfactorymethodforcreatingandreturninganinstance

ofFixedDepositDaobasedontheargumentpassedtothestaticmethod:

Examplelisting2-4–FixedDepositDaoFactoryclass



publicclassFixedDepositDaoFactory{

privateFixedDepositDaoFactory(){}



publicstaticFixedDepositDaogetFixedDepositDao(StringdaoType){

FixedDepositDaofixedDepositDao=null;



if("jdbc".equalsIgnoreCase(daoType)){

fixedDepositDao=newFixedDepositJdbcDao();

}

if("hibernate".equalsIgnoreCase(daoType)){

fixedDepositDao=newFixedDepositHibernateDao();

}

.....

returnfixedDepositDao;

}

}

TheaboveexamplelistingshowsthattheFixedDepositDaoFactoryclassdefinesagetFixedDepositDao

staticmethodthatcreatesandreturnsaninstanceofFixedDepositJdbcDao,FixedDepositHibernateDao

orFixedDepositIbatisDaoclass,dependingonthevalueofthedaoTypeargument.

ThefollowingbeandefinitionfortheFixedDepositDaoFactoryclassinstructsSpringcontainertoinvoke

FixedDepositDaoFactory’sgetFixedDepositDao method to obtain an instance of FixedDepositJdbcDao

class:

Examplelisting2-5–BeandefinitionfortheFixedDepositDaoFactoryclass



<beanid="dao"class="sample.spring.FixedDepositDaoFactory"

factory-method="getFixedDepositDao">

<constructor-argindex=”0”value="jdbc"/>

</bean>

Intheabovebeandefinition,classattributespecifiesthefully-qualifiednameoftheclassthatdefinesthe

staticfactorymethod.Thefactory-methodattributespecifiesthenameofthestaticfactorymethodthatthe

SpringcontainerinvokestoobtainaninstanceofFixedDepositDaoobject.The<constructor-arg>element

is defined in Spring’s beansschema and is used for passing arguments to constructors, and static and

instancefactorymethods.Theindexattributereferstothelocationoftheargumentintheconstructor,orin

thestaticorinstancefactorymethod.Intheabovebeandefinition,thevalue0ofindexattributemeans

that the <constructor-arg> element is supplying value for the first argument, which is daoType, of the

getFixedDepositDaofactorymethod.Thevalueattributespecifiestheargumentvalue.Ifafactorymethod

acceptsmultiplearguments,youneedtodefinea<constructor-arg>elementforeachofthearguments.

ItisimportanttonotethatcallingApplicationContext’sgetBeanmethodtoobtaindaobean(referexample

listing 2-5) will result in invocation of the FixedDepositDaoFactory’s getFixedDepositDao factory

method. This means that calling getBean("dao") returns the FixedDepositDao instance created by the

getFixedDepositDaofactorymethod,andnotaninstanceofFixedDepositDaoFactoryclass.

Now,thatwehaveseentheconfigurationofthefactoryclassthatcreatesaninstanceofFixedDepositDao,

the following example listing shows how to inject an instance of FixedDepositDao into

FixedDepositServiceImplclass:

Examplelisting2-6–Injectingobjectinstancescreatedbystaticfactorymethod



<beanid="service"class="sample.spring.chapter02.bankapp.FixedDepositServiceImpl">

<propertyname=“fixedDepositDao"ref="dao"/>

</bean>



<beanid="dao"class="sample.spring.chapter02.basicapp.FixedDepositDaoFactory"

factory-method="getFixedDepositDao">

<constructor-argindex=”0”value="jdbc"/>

</bean>



In the above example listing, <property> element injects an instance of FixedDepositDao returned by

FixedDepositDaoFactory’sgetFixedDepositDao factory methodintoFixedDepositServiceImpl instance.

If you compare the bean definition for the FixedDepositServiceImpl class shown above with the one

shown in example listing 2-3, you’ll notice that they are exactly the same. This shows that the bean

dependencies are specifiedthe same way irrespective of how (using no-argumentconstructor or static

factorymethod)theSpringcontainercreatesbeaninstances.

Let’snowlookathowSpringcontainerinstantiatebeansbyinvokinganinstancefactorymethod.

Instantiatingbeansviainstancefactorymethods

ThefollowingexamplelistingshowstheFixedDepositDaoFactoryclassthatdefinesaninstancefactory

methodforcreatingandreturninganinstanceofFixedDepositDao:

Examplelisting2-7–FixedDepositDaoFactoryclass



publicclassFixedDepositDaoFactory{

publicFixedDepositDaoFactory(){

}



publicFixedDepositDaogetFixedDepositDao(StringdaoType){

FixedDepositDaoFixedDepositDao=null;



if("jdbc".equalsIgnoreCase(daoType)){

FixedDepositDao=newFixedDepositJdbcDao();

}

if(“hibernate”.equalsIgnoreCase(daoType)){

FixedDepositDao=newFixedDepositHiberateDao();

}

.....

returnfixedDepositDao;

}

}

Ifaclassdefinesaninstancefactorymethod,theclassmustdefineapublicconstructorsothattheSpring

containercancreateaninstanceofthatclass.Intheaboveexamplelisting,theFixedDepositDaoFactory

class defines a public no-argument constructor. The FixedDepositDaoFactory’s getFixedDepositDao

methodisaninstancefactorymethodthatcreatesandreturnsaninstanceofFixedDepositDao.

The following example listing shows how to instruct Spring container to invoke

FixedDepositDaoFactory’sgetFixedDepositDaomethodtoobtainaninstanceofFixedDepositDao:

Examplelisting2-8–ConfigurationtoinvokeFixedDepositDaoFactory’sgetFixedDepositDaomethod



<beanid="daoFactory"class="sample.spring.chapter02.basicapp.FixedDepositDaoFactory"/>



<beanid="dao"factory-bean="daoFactory"factory-method="getFixedDepositDao">

<constructor-argindex="0"value="jdbc"/>

</bean>



<beanid="service"class="sample.spring.chapter02.bankapp.FixedDepositServiceImpl">

<propertyname=“fixedDepositDao"ref="dao"/>

</bean>



TheaboveexamplelistingshowsthattheFixedDepositDaoFactoryclass(aclassthatcontainsinstance

factory method) is configured like a regular Spring bean, and a separate <bean> element is used to

configuretheinstancefactorymethoddetails.Toconfiguredetailsofaninstancefactorymethod,factory-

beanandfactory-methodattributesof<bean>elementareused.Thefactory-bean attribute referstothe

beanthatdefinestheinstancefactorymethod,andthefactory-methodattributespecifiesthenameofthe

instance factory method. In the above example listing, <property> element injects an instance of

FixedDepositDao returned by FixedDepositDaoFactory’s getFixedDepositDao factory method into

FixedDepositServiceImplinstance.

Aswithstaticfactorymethods,youcanpassargumentstoinstancefactorymethodsusing<constructor-

arg> element. It is important to note that invoking ApplicationContext’sgetBean method to obtain dao

bean in the above example listing will result in invocation of the FixedDepositDaoFactory’s

getFixedDepositDaofactorymethod.

So far we have looked at bean definition examples in which dependencies are injected into beans via

settermethods.Let’snowlookatdifferentDImechanismsthatyoucanuseforinjectingdependencies.

2-4Dependencyinjectiontechniques

In Spring, dependency injection is performed by passing arguments to a bean’s constructor and setter

methods.Ifyouareusingastaticorinstancefactorymethodtocreatebeaninstances,youcanpassbean

dependencies to the factory method or you can set them on the bean instance returned by the factory

method.

We’llnowlookatexamplesthatdemonstratedifferentDItechniques.

Setter-basedDI

Sofarinthisbook,we’veseenexamplesofsetter-basedDI.Insetter-basedDI,<property>elementsare

used to specify bean dependencies. The <property> element is also used to pass configuration

information(ifany)requiredbythebean.

Let’ssaythattheMyBankapplicationcontainsaPersonalBankingServiceservicethatallowscustomers

toretrievebankaccountstatement,checkbankaccountdetails,updatecontactnumber,changepassword,

and contact customer service. The PersonalBankingService class uses JmsMessageSender (for sending

JMS messages), EmailMessageSender (for sending emails) and WebServiceInvoker (for invoking

external web services) objects toaccomplish it’s intended functionality. The following example listing

showsthePersonalBankingServiceclass:

Examplelisting2-9–PersonalBankingServiceclass



publicclassPersonalBankingService{

privateJmsMessageSenderjmsMessageSender;

privateEmailMessageSenderemailMessageSender;

privateWebServiceInvokerwebServiceInvoker;

.....

publicvoidsetJmsMessageSender(JmsMessageSenderjmsMessageSender){

this.jmsMessageSender=jmsMessageSender;

}



publicvoidsetEmailMessageSender(EmailMessageSenderemailMessageSender){

this.emailMessageSender=emailMessageSender;

}



publicvoidsetWebServiceInvoker(WebServiceInvokerwebServiceInvoker){

this.webServiceInvoker=webServiceInvoker;

}

.....

}

The above example listing shows that a setter method is defined for JmsMessageSender,

EmailMessageSenderandWebServiceInvokerdependenciesofPersonalBankingServiceclass.

We can use setter-based DI to inject the dependencies of the PersonalBankingService class, as shown

here:

Examplelisting2-10–BeandefinitionsforPersonalBankingServiceclassanditsdependencies



<beanid="personalBankingService"class="PersonalBankingService">

<propertyname="emailMessageSender"ref="emailMessageSender"/>

<propertyname="jmsMessageSender"ref="jmsMessageSender"/>

<propertyname="webServiceInvoker"ref="webServiceInvoker"/>

</bean>



<beanid="jmsMessageSender"class="JmsMessageSender">

.....

</bean>

<beanid="webServiceInvoker"class="WebServiceInvoker"/>

.....

</bean>

<beanid="emailMessageSender"class="EmailMessageSender"/>

.....

</bean>

The personalBankingService bean definition shows that a <property> element is specified for each

dependencyofPersonalBankingServiceclass.

PersonalBankingServiceusesEmailMessageSenderbeantosendanemailnotificationtothecustomer’s

emailaddressincasecustomerchangeshiscontactnumber.EmailMessageSenderrequiresemailserver

address, and username and password for authenticating with the email server. The following example

listingshowsthatthe<property>elementcanalsobeusedforsettingbeanpropertiesoftypeString:

Examplelisting2-11EmailMessageSenderclassandthecorrespondingbeandefinition

publicclassEmailMessageSender{

privateStringhost;

privateStringusername;

privateStringpassword;

.....

publicvoidsetHost(Stringhost){

this.host=host;

}



publicvoidsetUsername(Stringusername){

this.username=username;

}



publicvoidsetPassword(Stringpassword){

this.password=password;

}

.....

}



<beanid="emailMessageSender"class="EmailMessageSender">

<propertyname="host"value="smtp.gmail.com"/>

<propertyname="username"value="myusername"/>

<propertyname="password"value="mypassword"/>

</bean>

The above example listing shows that <property> elements have been used to set host, username and

passwordpropertiesofEmailMessageSenderbean.ThevalueattributespecifiestheStringvaluetobeset

for the bean property identified by the name attribute. The host, username and password properties

representconfigurationinformationrequiredbyEmailMessageSenderbean.Inchapter3,we’llseehow

the <property> element is used to set primitive type (like int, long, and so on), collection type (like

java.util.List,java.util.Map,andsoon)andcustomtype(likeAddress)properties.

Setter-based DI is also used to inject dependencies into beans created by static and instance factory

methods.Let’slookathowtousesetter-basedDIinconjunctionwithstaticandinstancefactorymethods.

Injectingdependenciesintobeaninstancescreatedbyfactorymethods

Youcanusesetter-basedDItoinjectdependenciesofthebeaninstancereturnedbyastaticorinstance

factorymethod.

ConsiderthefollowingFixedDepositJdbcDaoclassthatdefinesadatabaseInfoproperty:

Examplelisting2-12–FixedDepositJdbcDaoclass



publicclassFixedDepositJdbcDao{

privateDatabaseInfodatabaseInfo;

.....

publicFixedDepositJdbcDao(){}



publicvoidsetDatabaseInfo(DatabaseInfodatabaseInfo){

this.databaseInfo=databaseInfo;

}

.....

}

In the above example listing, the databaseInfo attribute represents a dependency of the

FixedDepositJdbcDaoclassthatisfulfilledbysetDatabaseInfomethod.

The following FixedDepositDaoFactory class defines a factory method responsible for creating and

returninganinstanceofFixedDepositDaoJdbcclass:

Examplelisting2-13–FixedDepositDaoFactoryclass



publicclassFixedDepositDaoFactory{

publicFixedDepositDaoFactory(){

}



publicFixedDepositDaogetFixedDepositDao(StringdaoType){

FixedDepositDaoFixedDepositDao=null;



if("jdbc".equalsIgnoreCase(daoType)){

FixedDepositDao=newFixedDepositJdbcDao();

}

if(“hibernate”.equalsIgnoreCase(daoType)){

FixedDepositDao=newFixedDepositHiberateDao();

}

.....

returnfixedDepositDao;

}

}

Intheaboveexamplelisting,thegetFixedDepositDaomethodisaninstancefactorymethodforcreating

FixedDepositDao instances. The getFixedDepositDao method creates an instance of

FixedDepositJdbcDaoinstanceifthevalueofdaoTypeargumentisjdbc.Itisimportanttonotethatthe

getFixedDepositDaomethoddoesn’tsetthedatabaseInfopropertyoftheFixedDepositJdbcDaoinstance.

Aswesawinexamplelisting2-8,thefollowingbeandefinitionsinstructSpringcontainertocreatean

instance of FixedDepositJdbcDao by invoking the getFixedDepositDao instance factory method of

FixedDepositDaoFactoryclass:



Examplelisting2-14–ConfigurationtoinvokeFixedDepositDaoFactory’sgetFixedDepositDaomethod



<beanid="daoFactory"class="FixedDepositDaoFactory"/>

<beanid="dao"factory-bean="daoFactory"factory-method="getFixedDepositDao">

<constructor-argindex="0"value="jdbc"/>

</bean>

ThedaobeandefinitionresultsininvocationofFixedDepositDaoFactory’sgetFixedDepositDaomethod,

which creates and returns an instance of FixedDepositJdbcDao. But, the FixedDepositJdbcDao’s

databaseInfopropertyisnotset.TosetthedatabaseInfodependency,youcanperformsetter-basedDIon

theFixedDepositJdbcDaoinstancereturnedbythegetFixedDepositDaomethod,asshownhere:

Examplelisting2-15–ConfigurationtoinvokeFixedDepositDaoFactory’sgetFixedDepositDaomethod

andsetdatabaseInfopropertyofreturnedFixedDepositJdbcDaoinstance

<beanid="daoFactory"class="FixedDepositDaoFactory"/>



<beanid="dao"factory-bean="daoFactory"factory-method="getFixedDepositDao">

<constructor-argindex="0"value="jdbc"/>

<propertyname="databaseInfo"ref="databaseInfo"/>

</bean>



<beanid="databaseInfo"class="DatabaseInfo"/>

The above bean definition shows that <property> element is used to set databaseInfo property of

FixedDepositJdbcDao instance returned by getFixedDepositDao instance factory method. As with the

instancefactorymethod,youcanusethe<property>elementtoinjectdependenciesintothebeaninstance

returnedbythestaticfactorymethod.

Let’snowlookathowtoinjectbeandependenciesviaconstructorarguments.

Constructor-basedDI

Inconstructor-basedDI,dependenciesofabeanarepassedasargumentstothebeanclass’sconstructor.

For instance, the following example listing shows PersonalBankingService class whose constructor

acceptsJmsMessageSender,EmailMessageSenderandWebServiceInvokerobjects:



Examplelisting2-16–PersonalBankingServiceclass



publicclassPersonalBankingService{

privateJmsMessageSenderjmsMessageSender;

privateEmailMessageSenderemailMessageSender;

privateWebServiceInvokerwebServiceInvoker;

.....

publicPersonalBankingService(JmsMessageSenderjmsMessageSender,

EmailMessageSenderemailMessageSender,

WebServiceInvokerwebServiceInvoker){



this.jmsMessageSender=jmsMessageSender;

this.emailMessageSender=emailMessageSender;

this.webServiceInvoker=webServiceInvoker;

}

.....

}

The arguments to the PersonalBankingService’s constructor represent dependencies of the

PersonalBankingService class. The following example listing shows how dependencies of

PersonalBankingServiceinstancearesuppliedvia<constructor-arg>elements:

Examplelisting2-17–PersonalBankingServicebeandefinition



<beanid="personalBankingService"class="PersonalBankingService">

<constructor-argindex="0"ref="jmsMessageSender"/>

<constructor-argindex="1"ref="emailMessageSender"/>

<constructor-argindex="2"ref="webServiceInvoker"/>

</bean>



<beanid="jmsMessageSender"class="JmsMessageSender">

.....

</bean>

<beanid="webServiceInvoker"class="WebServiceInvoker"/>

.....

</bean>

<beanid="emailMessageSender"class="EmailMessageSender"/>

.....

</bean>

In the above example listing, <constructor-arg> elements specify details of the constructor arguments

passedtothePersonalBankingServiceinstance.Theindexattributespecifiestheindexoftheconstructor

argument.Iftheindexattributevalueis0,itmeansthatthe<constructor-arg>elementcorrespondstothe

firstconstructorargument,andiftheindexattributevalueis1,itmeansthatthe<constructor-arg>element

correspondstothesecondconstructorargument,andsoon.Wesawearlierthatrefattributeof<property>

elementisusedforpassingreferencetoabean.Similarly,refattributeof<constructor-arg>elementis

usedforpassingreferencetoabean.Likethe<property>element,the<constructor-arg>elementisalso

usedtopassconfigurationinformation(ifany)requiredbythebean.

You should note that the <constructor-arg> element is also used for passing arguments to static and

instancefactorymethodsthatcreatebeaninstances(refersection2-3).

NOTE Instead of using ref attribute of <property> and <constructor-arg> elements, you can use <ref>

elementinsidethe<property>and<constructor-arg>elementstosetreferencetobeans.Therefattribute

ispreferredasitmakestheXMLlessverbose.

The following example listing shows the EmailMessageSender class and the corresponding bean

definitionthatdemonstratesuseof<constructor-arg>elementstosupplyvaluesforStringtypeconstructor

arguments:

Examplelisting2-18EmailMessageSenderclassandthecorrespondingbeandefinition

publicclassEmailMessageSender{

privateStringhost;

privateStringusername;

privateStringpassword;

.....

publicEmailMessageSender(Stringhost,Stringusername,Stringpassword){

this.host=host;

this.username=username;

this.password=password;

}

.....

}

<beanid="emailMessageSender"class="EmailMessageSender">

<constructor-argindex="0"value="smtp.gmail.com"/>

<constructor-argindex="1"value="myusername"/>

<constructor-argindex="2"value="mypassword"/>

</bean>

Sofarwehaveseenthat<constructor-arg>elementisusedforinjectingbeandependenciesandpassing

valuesforStringtypeconstructorarguments.Inchapter3,we’llseehowthe<constructor-arg>elementis

usedtosetprimitivetype(likeint,long,andsoon),collectiontype(likejava.util.List,java.util.Map,and

soon)andcustomtype(likeAddress)properties.

Let’snowlookathowwecanuseconstructor-basedDIalongwithsetter-basedDI.

Usingamixofconstructor-andsetter-basedDImechanisms

Ifabeanclassrequiresbothconstructor-andsetter-basedDImechanisms,youcanuseacombinationof

<constructor-arg>and<property>elementstoinjectdependencies.

The following example listing shows a bean class whose dependencies are injected as arguments to

constructorandsettermethods:

Examplelisting2-19–PersonalBankingServiceclass



publicclassPersonalBankingService{

privateJmsMessageSenderjmsMessageSender;

privateEmailMessageSenderemailMessageSender;

privateWebServiceInvokerwebServiceInvoker;

.....

publicPersonalBankingService(JmsMessageSenderjmsMessageSender,

EmailMessageSenderemailMessageSender){

this.jmsMessageSender=jmsMessageSender;

this.emailMessageSender=emailMessageSender;

}



publicvoidsetWebServiceInvoker(WebServiceInvokerwebServiceInvoker){

this.webServiceInvoker=webServiceInvoker;

}

.....

}

In the PersonalBankingService class, jmsMessageSender and emailMessageSender dependencies are

injected as constructor arguments, and webServiceInvoker dependency is injected via the

setWebServiceInvoker setter method. The following bean definition shows that both <constructor-arg>

and<property>elementsareusedtoinjectdependenciesofPersonalBankingServiceclass:

Examplelisting2-20–Mixingconstructor-andsetter-basedDImechanisms



<beanid="dataSource"class="PersonalBankingService">

<constructor-argindex="0"ref="jmsMessageSender"/>

<constructor-argindex="1"ref="emailMessageSender"/>

<propertyname="webServiceInvoker"ref="webServiceInvoker"/>

</bean>

Now,that we have seenhowtoinstructSpringcontainertocreatebeansand performDI,let’slookat

differentscopesthatyoucanspecifyforbeans.

2-5Beanscopes

Youmaywanttospecifythescopeofabeantocontrolwhetherasharedinstanceofthebeaniscreated

(singletonscope),oranewbeaninstanceiscreatedeverytimethebeanisrequested(prototypescope)

fromtheSpringcontainer.Thescopeofabeanisdefinedbythescopeattributeofthe<bean>element.If

thescopeattributeisnotspecified,itmeansthatthebeanisasingleton-scopedbean.

NOTEInwebapplicationscenarios,Springallowsyoutospecifyadditionalscopes:request,session

and globalSession. These scopes determine the lifetime of the bean instance. For instance, a request-

scoped bean’s lifetimeis limited toasingle HTTP request.Asin this chapter we’ll not be discussing

SpringWebMVCorSpringPortletMVC,we’llrestrictthediscussiontosingletonandprototypescopes.

Therequest,sessionandglobalSessionscopesaredescribedinchapter10.

IMPORTchapter2/ch02-bankapp-scopes(Thisproject shows usageof singletonandprototype bean

scopes.Toruntheapplication,executethemainmethodoftheBankAppclassofthisproject.Theproject

alsocontains2JUnittests,PrototypeTestandSingletonTestthatyoucanexecute)

Singleton

Thesingletonscopeisthedefaultscope for all the beansdefinedintheapplicationcontext XML file.

Instance of a singleton-scoped bean is created when the Spring container is created, and is destroyed

whentheSpringcontainerisdestroyed.Springcontainercreatesasingleinstanceofasingleton-scoped

bean,whichissharedbyallthebeansthatdependonit.

ThefollowingexamplelistingshowstheapplicationContext.xmlfileofch02-bankapp-scopesprojectin

whichallthebeansaresingleton-scoped:

Examplelisting2-21–applicationContext.xml-Singleton-scopedbeans

Project–ch02-bankapp-scopes

Sourcelocation-src/main/resources/META-INF/spring



<beans.....>

<beanid="controller"

class="sample.spring.chapter02.bankapp.controller.FixedDepositControllerImpl">

<propertyname=“fixedDepositService"ref="service"/>

</bean>



<beanid="service"

class="sample.spring.chapter02.bankapp.service.FixedDepositServiceImpl">

<propertyname=“fixedDepositDao"ref="dao"/>

</bean>



<beanid="dao"class="sample.spring.chapter02.bankapp.dao.FixedDepositDaoImpl"/>

.....

</beans>

IntheaboveapplicationContext.xmlfile,controller,serviceanddaobeansaresingleton-scopedbecause

no scope attribute is specified for the <bean> elements. This means that only a single instance of

FixedDepositControllerImpl,FixedDepositServiceImplandFixedDepositDaoImpl classes is createdby

theSpringcontainer.Asthesebeansaresingleton-scoped,Springcontainerreturnsthesameinstanceof

thebeaneverytimeweretrieveoneofthesebeansusingApplicationContext’sgetBeanmethod.

NOTEIfthescopeattributeisnotspecifiedorthevalueofscopeattributeissingleton,itmeansthatthe

beanissingleton-scoped.

ThefollowingexamplelistingshowsthetestInstancesmethodofSingletonTest(aJUnittestclass)classof

ch02-bankapp-scopes project. The testInstances method tests whether multiple invocation of

ApplicationContext’sgetBeanmethodreturnsthesameordifferentinstanceofthecontrollerbean:

Examplelisting2-22–SingletonTestJUnittestclass

Project–ch02-bankapp-scopes

Sourcelocation-src/test/java/sample/spring/chapter02/bankapp



packagesample.spring.chapter02.bankapp;



importstaticorg.junit.Assert.assertSame;

importorg.junit.BeforeClass;

importorg.junit.Test;



importsample.spring.chapter02.bankapp.controller.FixedDepositController;



publicclassSingletonTest{

privatestaticApplicationContextcontext;



@BeforeClass

publicstaticvoidinit(){

context=newClassPathXmlApplicationContext(

"classpath:META-INF/spring/applicationContext.xml");

}



@Test

publicvoidtestInstances(){

FixedDepositControllercontroller1=(FixedDepositController)context.getBean("controller");

FixedDepositControllercontroller2=(FixedDepositController)context.getBean("controller");

assertSame("DifferentFixedDepositControllerinstances",controller1,controller2);

}

.....

}

Intheaboveexamplelisting,JUnit’s@BeforeClassannotationspecifiesthattheinitmethodisinvoked

beforeanyofthetestmethods(thatis,methodsannotatedwithJUnit’s@Testannotation)intheclass.This

means that @BeforeClass annotated method is invoked only once, and @Test annotated methods are

executedonlyaftertheexecutionof@BeforeClassannotatedmethod.Notethattheinitmethodisastatic

method. The init method creates an instance of ApplicationContext object by passing the configuration

metadata (shown in example listing 2-21) to the ClassPathXmlApplicationContext’s constructor. The

testInstancesmethodobtains2instancesofcontrollerbeanandcheckswhetherboththeinstancesarethe

samebyusingJUnit’sassertSameassertion.Asthecontrollerbeanissingleton-scoped,controller1and

controller2 bean instances are the same. For this reason, SingletonTest’s testInstances test executes

withoutanyassertionerrors.

ThefollowingfigureshowsthattheSpringcontainerreturnsthesameinstanceofcontrollerbeanwhen

youcalltheApplicationContext’sgetBeanmethodmultipletimes:

Figure2-4Multiplerequestsforasingleton-scopedbeanresultsinthesamebeaninstancereturnedbythe

Springcontainer

The above figure shows that multiple calls to obtain controller bean returns the same instance of the

controllerbean.



NOTEInfigure2-4,thecontrollerbeaninstanceisrepresentedbya2-compartmentrectangle.Thetop

compartmentshowsthenameofthebean(thatis,thevalueoftheidattributeofthe<bean>element)and

thebottomcompartmentshowsthetypeofthebean(thatis,thevalueoftheclassattributeofthe<bean>

element). In the rest of this book, we’ll use this convention to show bean instances inside a Spring

container.

Asingleton-scopedbeaninstanceissharedamongstthebeansthatdependonit.Thefollowingexample

listing shows the testReference method of SingletonTest JUnit test class that checks if the

FixedDepositDao instance referenced by the FixedDepositController instance is the same as the one

obtaineddirectlybycallinggetBeanmethodofApplicationContext:

Examplelisting2-23–testReferencemethodofSingletonTestJUnittestclass

Project–ch02-bankapp-scopes

Sourcelocation-src/test/java/sample/spring/chapter02/bankapp



packagesample.spring.chapter02.bankapp;



importstaticorg.junit.Assert.assertSame;

importorg.junit.Test;



publicclassSingletonTest{

privatestaticApplicationContextcontext;

.....

@Test

publicvoidtestReference(){

FixedDepositControllercontroller=(FixedDepositController)context.getBean("controller");



FixedDepositDaofixedDepositDao1=

controller.getFixedDepositService().getFixedDepositDao();

FixedDepositDaofixedDepositDao2=(FixedDepositDao)context.getBean("dao");

assertSame("DifferentFixedDepositDaoinstances",fixedDepositDao1,fixedDepositDao2);

}

}

Intheaboveexamplelisting,thetestReferencemethodfirstretrievestheFixedDepositDaoinstance(refer

fixedDepositDao1variableintheaboveexamplelisting)referencedbytheFixedDepositControllerbean,

followed by directly retrieving another instance of FixedDepositDao bean (refer fixedDepositDao2

variable in the above example listing) using ApplicationContext’s getBean method. If you execute the

testReference test, you’ll see that the test completes successfully because the fixedDepositDao1 and

fixedDepositDao2instancesarethesame.

Figure2-5showsthattheFixedDepositDaoinstancereferencedbyFixedDepositControllerinstanceisthe

sameastheonereturnedbyinvokinggetBean("dao")methodonApplicationContext.

Figure2-5Singleton-scopedbeaninstanceissharedbetweenbeansthatdependonit

TheabovefigureshowsthattheFixedDepositDaoinstancereferencedbyFixedDepositController bean

instance and the one retrieved directly by calling ApplicationContext’s getBean are same. If there are

multiple beans dependent on a singleton-scoped bean, then all the dependent beans share the same

singleton-scopedbeaninstance.

Let’s now look at whether or not the same singleton-scoped bean instance is shared between multiple

Springcontainerinstances.

Singleton-scopedbeansandmultipleSpringcontainerinstances

Thescopeofasingleton-scopedbeaninstanceislimitedtotheSpringcontainerinstance.Thismeansthat

if you create 2 instances of the Spring container using the same configuration metadata, each Spring

containerhasitsowninstancesofthesingleton-scopedbeans.

ThefollowingexamplelistingshowsthetestSingletonScopemethodofSingletonTestclass,whichtests

whethertheFixedDepositControllerbeaninstanceretrievedfromtwodifferentSpringcontainerinstances

aresameordifferent:



Examplelisting2-24–testSingletonScopemethodofSingletonTestJUnittestclass

Project–ch02-bankapp-scopes

Sourcelocation-src/test/java/sample/spring/chapter02/bankapp

packagesample.spring.chapter02.bankapp;



importstaticorg.junit.Assert.assertNotSame;



publicclassSingletonTest{

privatestaticApplicationContextcontext;

.....

@BeforeClass

publicstaticvoidinit(){

context=newClassPathXmlApplicationContext(

"classpath:META-INF/spring/applicationContext.xml");

}



@Test

publicvoidtestSingletonScope(){

ApplicationContextanotherContext=newClassPathXmlApplicationContext(

"classpath:META-INF/spring/applicationContext.xml");



FixedDepositControllerfixedDepositController1=(FixedDepositController)anotherContext

.getBean("controller");



FixedDepositControllerfixedDepositController2=

(FixedDepositController)context.getBean("controller");



assertNotSame("SameFixedDepositControllerinstances",

fixedDepositController1,fixedDepositController2);

}

}

TheSingletonTest’sinitmethod(annotatedwithJUnit’s@BeforeClassannotation)createsaninstanceof

ApplicationContext(identifiedbycontextvariable)beforeany@Testannotatedmethodisexecuted.The

testSingletonScopemethodcreates one more instance ofSpring container (identifiedbyanotherContext

variable) using the same applicationContext.xml file. An instance of FixedDepositController bean is

retrieved from both the Spring containers and checked if they are not the same. If you execute the

testSingletonScope test, you’ll find that the test completes successfully because the

FixedDepositControllerbeaninstanceretrievedfromcontextinstanceisdifferentfromtheoneretrieved

fromanotherContextinstance.

ThefollowingfiguredepictsthebehaviorexhibitedbythetestSingletonScopemethod:

Figure2-6EachSpringcontainercreatesitsowninstanceofasingleton-scopedbean

TheabovefigureshowsthateachSpringcontainercreatesitsowninstanceofcontrollerbean.Thisisthe

reasonwhycontextandanotherContextinstancesreturndifferentinstancesofcontrollerbeanwhenyou

callgetBean("controller")method.

ThetestSingletonScopemethodshowedthateachSpringcontainercreatesitsowninstanceofasingleton-

scopedbean.ItisimportanttonotethatSpringcontainercreatesaninstanceofasingleton-scopedbean

for each bean definition. The following example listing shows multiple bean definitions for the

FixedDepositDaoImplclass:

Examplelisting2-25–applicationContext.xml-Multiplebeandefinitionsforthesameclass

Project–ch02-bankapp-scopes

Sourcelocation-src/main/resources/META-INF/spring



<beanid="dao"class="sample.spring.chapter02.bankapp.dao.FixedDepositDaoImpl"/>

<beanid="anotherDao"

class="sample.spring.chapter02.bankapp.dao.FixedDepositDaoImpl"/>

ThebeandefinitionsshownintheaboveexamplelistingareforFixedDepositDaoImplclass.Asscope

attributeisnotspecified,beandefinitionsshownintheaboveexamplelistingrepresentsingleton-scoped

beans.Evenifmultiplebeandefinitionsaredefinedforaclass,Springcontainercreatesabeaninstance

corresponding to each bean definition. This means that Spring container creates distinct instances of

FixedDepositDaoImpl class corresponding to dao and anotherDao bean definitions. The following

example listing shows SingletonScope’s testSingletonScopePerBeanDef method that tests whether the

FixedDepositDaoImpl instances corresponding to dao and anotherDao bean definitions are same or

different:

Examplelisting2-26–testSingletonScopePerBeanDefmethodofSingletonTestJUnittestclass

Project–ch02-bankapp-scopes

Sourcelocation-src/test/java/sample/spring/chapter02/bankapp

packagesample.spring.chapter02.bankapp;



importstaticorg.junit.Assert.assertNotSame;



publicclassSingletonTest{

privatestaticApplicationContextcontext;

.....

@Test

publicvoidtestSingletonScopePerBeanDef(){

FixedDepositDaofixedDepositDao1=(FixedDepositDao)context.getBean("dao");

FixedDepositDaofixedDepositDao2=(FixedDepositDao)context.getBean("anotherDao");

assertNotSame("SameFixedDepositDaoinstances",fixedDepositDao1,fixedDepositDao2);

}

}

Intheaboveexamplelisting,fixedDepositDao1andfixedDepositDao2variablesrepresentinstancesof

FixedDepositDaoImplclassthatSpringcontainercreatescorrespondingtothedaoandanotherDaobean

definitions, respectively. If you execute the testSingleScopePerBeanDef test, it’ll execute without any

assertion errors because the fixedDepositDao1 instance (corresponding to dao bean definition) and

fixedDepositDao2instance(correspondingtoanotherDaobeandefinition)aredistinct.

Thefollowingfiguresummarizesthatasingleton-scopedbeaniscreatedperbeandefinition:

Figure2-7Thereisonesingleton-scopedbeaninstanceperbeandefinition

Theabovefigureshowsthatthereexistsoneinstanceofsingleton-scopedbeanperbeandefinitioninthe

Springcontainer.

We mentioned earlier that a singleton-scoped bean is pre-instantiated by default, which means an

instanceofasingleton-scopedbeaniscreatedwhenyoucreateaninstanceoftheSpringcontainer.Let’s

nowlookathowyoucanlazilyinitializeasingleton-scopedbean.

Lazilyinitializingasingleton-scopedbean

You can instruct Spring container to create an instance of a singleton-scoped bean only when it is

requested for the first time. The following lazyExample bean definition shows how to instruct Spring

containertolazyinitializelazyBeanbean:

Examplelisting2-27–Lazilyinitializingasingleton-scopedbean



<beanid="lazyBean"class="example.LazyBean"lazy-init=”true”/>

The<bean>element’slazy-initattributespecifieswhetherthebeaninstanceiscreatedlazilyoreagerly.If

thevalueistrue(asincaseofthebeandefinitionshownabove),thebeaninstanceisinitializedbythe

Springcontainerwhenitreceivestherequestforthebeanforthefirsttime.

Thefollowingsequencediagramshowshowlazy-initattributeaffectsthecreationofasingleton-scoped

beaninstance:

Figure2-8Alazily-initializedsingleton-scopedbeaninstanceiscreatedwhenitisrequestedforthefirst

timebytheapplication

In the above diagram, BeanA represents a singleton-scoped bean instance that is not set to be lazily-

initialized,andLazyBeanrepresentsasingleton-scopedbeanthatissettobelazily-initialized.Whenthe

Spring container instance is created, BeanA is also instantiated because it is not set to be lazily-

initialized. On the other hand, LazyBean is instantiated when ApplicationContext’s getBean method is

invokedforthetimefirsttimetoretrieveaninstanceofLazyBeanfromtheSpringcontainer.

NOTEYoucanuse<beans>element’sdefault-lazy-initattributetospecifydefaultinitializationstrategy

forbeansdefinesintheapplicationcontextXMLfile.Ifthe<bean>element’slazy-initattributespecifies

adifferentvaluethanthe<beans>element’sdefault-lazy-init,thevaluespecifiedbythelazy-initattribute

appliestothebean.

Asasingleton-scopedbeancanbelazily-initializedorpre-instantiatedbytheSpringcontainer,youmay

bethinkingatthistimewhetheryoushoulddefineyoursingleton-scopedbeanstobelazily-initializedor

pre-instantiated.Inmostapplicationscenarios,itisbeneficialtopre-instantiatesingleton-scopedbeansto

discover configuration issues at the time of creation of the Spring container. The following example

listingshowsaaBeansingleton-scopedbeanthatissettobelazily-initialized,andthatdependsonbBean

bean:

Examplelisting2-28–Alazily-initializedsingleton-scopedbean



publicclassABean{

privateBBeanbBean;



publicvoidsetBBean(BBeanbBean){

this.bBean=bBean;

}

.....

}



<beanid="aBean"class="ABean"lazy-init="true">

<propertyname="bBean"value="bBean"/>

</bean>



<beanid="bBean"class="BBean"/>

Intheaboveexamplelisting,ABean’sbBeanpropertyreferstotheBBeanbean.Noticethatinsteadofref

attribute, value attribute of <property> element has been used to set ABean’s bBean property. If you

createanApplicationContextinstancebypassingittheXMLfilecontainingtheabovebeandefinition,no

errors will be reported. But, when you try to fetch the aBean bean by invoking ApplicationContext’s

getBeanmethod,you’llgetthefollowingerrormessage:

Causedby:java.lang.IllegalStateException:Cannotconvertvalueoftype[java.lang.String]torequiredtype[BBean]forproperty'bBean:no

matchingeditorsorconversionstrategyfound

The above error message is shown because the Spring container fails to convert the String value of

ABean’sbBeanpropertytoBBeantype.Thishighlightsasimpleconfigurationissueinwhichinsteadof

specifying<bean>element’srefattribute,valueattributewasspecified.IftheaBeanbeanwasdefinedas

pre-instantiated(insteadoflazily-initialized),theaboveconfigurationissuecouldhavebeencaughtatthe

timewecreatedaninstanceofApplicationContext,andnotwhenwetriedtoobtainaninstanceofaBean

beanfromtheApplicationContext.

Let’snowlookatprototype-scopedbeansinSpring.

Prototype

Aprototype-scopedbeanisdifferentfromasingleton-scopedbeaninthesensethattheSpringcontainer

always returns a new instance of a prototype-scoped bean. Another distinctive feature of prototype-

scopedbeansisthattheyarealwayslazily-initialized.

The following FixedDepositDetails bean in the applicationContext.xml file of ch02-bankapp-scopes

projectrepresentsaprototype-scopedbean:

Examplelisting2-29–applicationContext.xml-Aprototype-scopedbeanexample

Project–ch02-bankapp-scopes

Sourcelocation-src/main/resources/META-INF/spring



<beanid="FixedDepositDetails"

class="sample.spring.chapter02.bankapp.domain.FixedDepositDetails"

scope="prototype"/>

Theaboveexamplelistingshowsthatthe<bean>element’sscopeattributevalueissettoprototype.This

meansthattheFixedDepositDetailsbeanisaprototype-scopedbean.

The following testInstances method of PrototypeTest JUnit test class shows that the 2 instances of

FixedDepositDetailsbeanretrievedfromtheSpringcontaineraredifferent:

Examplelisting2-30–testInstancesmethodofPrototypeTestJUnittestclass

Project–ch02-bankapp-scopes

Sourcelocation-src/test/java/sample/spring/chapter02/bankapp

packagesample.spring.chapter02.bankapp;



importstaticorg.junit.Assert.assertNotSame;



publicclassPrototypeTest{

privatestaticApplicationContextcontext;

.....

@Test

publicvoidtestInstances(){

FixedDepositDetailsfixedDepositDetails1=

(FixedDepositDetails)context.getBean("fixedDepositDetails");

FixedDepositDetailsfixedDepositDetails2=

(FixedDepositDetails)context.getBean("fixedDepositDetails");



assertNotSame("SameFixedDepositDetailsinstances",

fixedDepositDetails1,fixedDepositDetails2);

}

}

If you execute the testInstances test, it’ll complete without any assertion errors because the 2

FixedDepositDetails instances (fixedDepositDetails1 and fixedDepositDetails2) obtained from the

ApplicationContextaredifferent.

Let’snowlookathowtochoosetherightscope(singletonorprototype)forabean.

Choosingtherightscopeforyourbeans

Ifabeandoesn’tmaintainanyconversationalstate(thatis,itisstatelessinnature),itshouldbedefinedas

a singleton-scoped bean. If a bean maintains conversational state, it should be defined as a prototype-

scopedbean.FixedDepositServiceImpl,FixedDepositDaoImplandFixedDepositControllerImplbeansof

MyBank application are stateless in nature; therefore, they are defined as singleton-scoped beans.

FixedDepositDetails bean (a domain object) of MyBank application maintains conversational state;

therefore,itisdefinedasaprototype-scopedbean.

NOTEIfyouareusinganORMframework(likeHibenateoriBATIS)inyourapplication,thedomain

objectsarecreatedeitherbytheORMframeworkoryoucreatethemprogrammaticallyinyour

applicationcodeusingthenewoperator.Itisbecauseofthisreasondomainobjectsarenotdefinedinthe

applicationcontextXMLfileiftheapplicationusesanORMframeworkforpersistence.

2-6Summary

In this chapter,we discussed some ofthe basics ofSpring Framework.We looked at ‘programming to

interfaces’designapproach,differentapproachestocreatebeaninstances,constructor-basedDIandbean

scopes.Inthenextchapter,we’lllookathowtosetdifferenttypes(likeint,long,Map,Set,andsoon)of

beanpropertiesandconstructorarguments.

Chapter3-Configuringbeans

3-1Introduction

Inpreviouschapters,wetoucheduponsomeofthebasicconceptsofSpringFramework.Wesawhow

SpringbeansandtheirdependenciesarespecifiedintheapplicationcontextXMLfile.Wealsolookedat

singleton-andprototype-scopedbeans,anddiscussedtheimplicationsofassigningthesescopestobeans.

Inthischapter,we’lllookat:

§beandefinitioninheritance

§howargumentstoabeanclass’sconstructorareresolved

§howtoconfigurebeanpropertiesandconstructorargumentsofprimitivetype(likeint,float,andso

on),collectiontype(likejava.util.List,java.util.Map,andsoon),customtype(likeAddress),and

soon

§ how you can make the application context XML file less verbose by using p-namespace and c-

namespacetospecifybeanpropertiesandconstructorarguments,respectively

§Spring’sFactoryBeaninterfacethatallowsyoutowriteyourownfactoryclassfor creatingbean

instances

3-2Beandefinitioninheritance

Wesawinchapter1and2thatabeandefinitionintheapplicationcontextXMLfilespecifiesthefully-

qualifiednameofthebeanclassanditsdependencies.Insomescenarios,tomakeabeandefinitionless

verbose,youmaywantabeandefinitiontoinheritconfigurationinformationfromanotherbeandefinition.

Let’slookatonesuchscenarioinMyBankapplication.

IMPORTchapter3/ch03-bankapp-inheritance(Thisproject showstheMyBankapplicationthatuses

beandefinitioninheritance.Toruntheapplication,executethemainmethodoftheBankAppclassofthis

project)

MyBank–Beandefinitioninheritanceexample

Inthepreviouschapter,wesawthattheMyBankapplicationaccessesdatabasethroughDAOs.Let’ssay

that the MyBank application defines a DatabaseOperations class that simplifies interacting with the

database.So,alltheDAOsintheMyBankapplicationdependonDatabaseOperationsclasstoperform

databaseoperations,asshowninthefollowingfigure:

Figure 3-1 - DAO classes in MyBank application make use of DatabaseOperations class to perform

databaseinteraction

TheabovefigureshowsthattheFixedDepositDaoandPersonalBankingDaoclassesaredependentonthe

DatabaseOperations class. The following application context XML file shows the bean definitions for

theseclasses:

Examplelisting3-1–DAObeansaredependentonDatabaseOperationsbean



<beanid="databaseOperations"

class="sample.spring.chapter01.bankapp.utils.DatabaseOperations"/>



<beanid="personalBankingDao"

class="sample.spring.chapter01.bankapp.dao.PersonalBankingDaoImpl">

<propertyname="databaseOperations"ref="databaseOperations"/>

</bean>



<beanid="FixedDepositDao"

class="sample.spring.chapter01.bankapp.dao.FixedDepositDaoImpl">

<propertyname="databaseOperations"ref="databaseOperations"/>

</bean>

Both the personalBankingDao and FixedDepositDao bean definitions use the <property> element to

performdependencyinjectionoftheDatabaseOperationsinstance.Asthenameofthepropertythatrefers

totheDatabaseOperationsinstanceisdatabaseOperationsinboththebeandefinitions,itimpliesthatboth

PersonalBankingDaoImpl and FixedDepositDaoImpl classes define a setDatabaseOperations method to

allowSpringcontainertoinjectDatabaseOperationsinstance.

If multiple beans in your application share a common set of configuration (properties, constructor

arguments,andsoon),youcancreateabeandefinitionthatactsasaparentforotherbeandefinitions.In

case of personalBankingDao and fixedDepositDao bean definitions, the common configuration is the

databaseOperations property. The following example listing shows that the personalBankingDao and

fixedDepositDaobeandefinitionsmakeuseofbeandefinitioninheritance:

Examplelisting3-2–applicationContext.xml-MyBank’sapplicationcontextXMLfile

Project–ch03-bankapp-inheritance

Sourcelocation-src/main/resources/META-INF/spring



<beanid="databaseOperations"

class="sample.spring.chapter03.bankapp.utils.DatabaseOperations"/>



<beanid="daoTemplate"abstract="true">

<propertyname="databaseOperations"ref="databaseOperations"/>

</bean>



<beanid="FixedDepositDao"parent="daoTemplate"

class="sample.spring.chapter03.bankapp.dao.FixedDepositDaoImpl"/>



<beanid="personalBankingDao"parent="daoTemplate"

class="sample.spring.chapter03.bankapp.dao.PersonalBankingDaoImpl"/>

Intheaboveexamplelisting,thedaoTemplatebeandefinitiondefinesthecommonconfigurationsharedby

both the fixedDepositDao and personalBankingDao bean definitions. As both the fixedDepositDao and

personalBankingDaobeandefinitionsrequirethedatabaseOperationsdependency(referexamplelisting

3-1),thedaoTemplatebeandefinitiondefinesthedatabaseOperationsdependencyusingthe<property>

element.The<bean>element’sparentattributespecifiesthenameofthebeandefinitionfromwhichthe

configuration is inherited. As the parent attribute value is daoTemplate for fixedDepositDao and

personalBankingDao bean definitions, they inherit databaseOperations property from the daoTemplate

beandefinition.Theexamplelistings3-1and3-2aresame,exceptthattheexamplelisting3-2makesuse

ofbeandefinitioninheritance.

Ifthe<bean>element’sabstractattributevalueissettotrue,itmeansthatthebeandefinitionisabstract.

It is important to note that the Spring container doesn’t attempt to create a bean corresponding to an

abstractbeandefinition.Itisimportanttonotethatyoucan’tdefineabeantobedependentonanabstract

bean,thatis,youcan’tuse<property>or<constructor-arg>elementtorefertoanabstractbean.

In example listing 3-2, daoTemplate bean definition is abstract. You may have noticed that the

daoTemplatebeandefinitiondoesn’tspecifytheclassattribute.Ifaparentbeandefinitiondoesn’tspecify

theclassattribute,childbeandefinitions(likethefixedDepositDaoandpersonalBankingDao)specifythe

class attribute. It is important to note that if you don’t specify the class attribute, you must define the

parent bean definition as abstract so that Spring container doesn’t attempt to create a bean instance

correspondingtoit.

ToverifythatthefixedDepositDaoandpersonalBankingDaobeandefinitionsinheritdaoTemplate bean

definition’sdatabaseOperationsproperty,executethemainmethodofBankAppclass ofch03-bankapp-

inheritance project. BankApp’s main method invokes methods on the fixedDepositDao and

personalBankingDaobeans;thosebeansinturninvokemethodsontheDatabaseOperationsinstance.Ifa

DatabaseOperations instance is not injected into the fixedDepositDao and personalBankingDao beans,

java.lang.NullPointerExceptionwillbethrown.

ThefollowingdiagramsummarizeshowbeandefinitioninheritanceworksincaseofFixedDepositDao

andpersonalBankingDaobeandefinitions:

Figure3-2–BeandefinitioninheritanceinMyBankapplication

The above figure shows that the fixedDepositDaoand personalBankingDao bean definitions inherit the

databaseOperations property (shown in italics in the boxes labeled fixedDepositDao and

personalBankingDao)fromthedaoTemplatebeandefinition.TheabovefigurealsodepictsthattheSpring

container doesn’t attempt to create a bean instance corresponding to the daoTemplate bean definition

becauseitismarkedasabstract.

Let’snowlookatwhatconfigurationinformationgetsinheritedfromtheparentbeandefinition.

Whatgetsinherited?

Achildbeandefinitioninheritsthefollowingconfigurationinformationfromtheparentbeandefinition:

·properties–specifiedvia<property>elements

·constructorarguments–specifiedvia<constructor-arg>elements

·methodoverrides(discussedinsection4-5ofchapter4)

·initializationanddestroymethods(discussedinchapter5),and

·factorymethods–specifiedviafactory-methodattributeof<bean>element(refersection2-3of

chapter2toknowhowstaticandinstancefactorymethodsareusedforcreatingbeans)

IMPORTchapter3/ch03-bankapp-inheritance-example(ThisprojectshowstheMyBankapplication

thatusesbeandefinitioninheritance.Inthisproject,you’llseemultiplescenariosinwhichbeandefinition

inheritanceisused.Toruntheapplication,executethemainmethodoftheBankAppclassofthisproject)

Let’snowlookatsomeofthebeandefinitioninheritanceexamples.

Beandefinitioninheritanceexample–parentbeandefinitionisnotabstract

Thefollowingexamplelistingshowsabeaninheritanceexampleinwhichtheparentbeandefinitionis

notabstract,andthechildbeandefinitionsdefineanadditionaldependency:

Examplelisting3-3–applicationContext.xml-Beandefinitioninheritance–parentbeandefinitionisnot

abstract

Project–ch03-bankapp-inheritance-examples

Sourcelocation-src/main/resources/META-INF/spring



<beanid="serviceTemplate"

class="sample.spring.chapter03.bankapp.base.ServiceTemplate">

<propertyname="jmsMessageSender"ref="jmsMessageSender"/>

<propertyname="emailMessageSender"ref="emailMessageSender"/>

<propertyname="webServiceInvoker"ref="webServiceInvoker"/>

</bean>



<beanid="fixedDepositService"class=".....FixedDepositServiceImpl"

parent="serviceTemplate">

<propertyname=“fixedDepositDao"ref="fixedDepositDao"/>

</bean>



<beanid="personalBankingService"class=".....PersonalBankingServiceImpl"

parent="serviceTemplate">

<propertyname="personalBankingDao"ref="personalBankingDao"/>

</bean>



<beanid="userRequestController"class=".....UserRequestControllerImpl">

<propertyname="serviceTemplate"ref="serviceTemplate"/>

</bean>

A littlebackgroundbefore we delve into the details ofthe above listedconfiguration: a service inthe

MyBank application may send JMS messages to a messaging-middleware or send emails to an email

server or it may invokean external web service. Intheabove example listing, the jmsMessageSender,

emailMessageSender and webServiceInvoker beans simplify these tasks by providing a layer of

abstraction.TheserviceTemplatebeanprovidesaccesstojmsMessageSender,emailMessageSenderand

webServiceInvoker beans. This is the reason why the serviceTemplate bean is dependent on the

jmsMessageSender,emailMessageSenderandwebServiceInvokerbeans.

Example listing 3-3 shows that the serviceTemplate bean definition is the parent bean definition of

fixedDepositServiceandpersonalBankingServicebeandefinitions.NoticethattheserviceTemplatebean

definitionisnotabstract;theclassattributespecifiesServiceTemplateastheclass.Inourpreviousbean

definition inheritance example (refer example listing 3-2), child bean definitions didn’t define any

properties.Intheaboveexamplelisting,noticethatthefixedDepositServiceandpersonalBankingService

childbeandefinitionsdefinefixedDepositDaoandpersonalBankingDaoproperties,respectively.

As parent bean definition’s properties are inherited by the child bean definitions,

FixedDepositServiceImpl and PersonalBankingServiceImpl classes must define setter methods for

jmsMessageSender, emailMessageSender and webServiceInvoker properties. You have the option to

either define setter methods in FixedDepositServiceImpl and PersonalBankingServiceImpl classes or

make FixedDepositServiceImpl and PersonalBankingServiceImpl classes as subclasses of

ServiceTemplate class. In ch03-bankapp-inheritance-examples, the FixedDepositServiceImpl and

PersonalBankingServiceImplclassesaresubclassesofServiceTemplateclass.

ThefollowingexamplelistingshowsthePersonalBankingServiceImplclass:

Examplelisting3-4–PersonalBankingServiceImplclass

Project–ch03-bankapp-inheritance-examples

Sourcelocation-src/main/java/sample/spring/chapter03/bankapp/service



packagesample.spring.chapter03.bankapp.service;



publicclassPersonalBankingServiceImplextendsServiceTemplateimplements

PersonalBankingService{



privatePersonalBankingDaopersonalBankingDao;



publicvoidsetPersonalBankingDao(PersonalBankingDaopersonalBankingDao){

this.personalBankingDao=personalBankingDao;

}



@Override

publicBankStatementgetMiniStatement(){

returnpersonalBankingDao.getMiniStatement();

}

}

In example listing 3-3, we saw that the personalBankingService bean definition specifies

personalBankingDao as a dependency. In the above example listing, the setPersonalBankingDao setter

method corresponds to the personalBankingDao dependency. Also, notice that the

PersonalBankingServiceImplclassisasubclassoftheServiceTemplateclass.

Thefollowingdiagramshowsthataparentbeandefinition(likeserviceTemplate)neednotbeabstract,

child bean definitions (like fixedDepositService and personalBankingService) may define additional

properties, and classes represented by parent (like ServiceTemplate class) and child bean definitions

(like FixedDepositServiceImpl and PersonalBankingServiceImpl) may themselves be related by

inheritance:

Figure3-3–Childbeandefinitionsaddadditionalproperties,parentbeandefinitionisnotabstract,and

parent-childrelationshipexistsbetweentheclassesrepresentedbytheparentandchildbeandefinitions

Figure3-3shows:

·SpringcontainercreatesaninstanceofserviceTemplatebeanbecauseit’snotdefinedasabstract

·FixedDepositServiceImplandPersonalBankingServiceImplclasses(correspondingtothechild

bean definitions) are subclasses of ServiceTemplate class – the class corresponding to the

serviceTemplateparentbeandefinition.

·        And, fixedDepositService and personalBankingService bean definitions define additional

properties,fixedDepositDaoandpersonalBankingDao,respectively.Youshouldnotethatthechild

beandefinitionscanalsodefineadditionalconstructorargumentsandmethodoverrides(discussed

insection4-5).

AsserviceTemplatebeandefinitionisnotabstract,otherbeanscandefineserviceTemplatebeanastheir

dependency. For instance, in example listing 3-3, the serviceTemplate bean is a dependency of

userRequestController bean. You can infer from this discussion that if a parent bean definition is not

abstract,thefunctionalityofferedbytheparentbeancanbeutilizednotonlybychildbeansbutalsoby

otherbeansintheapplicationcontext.

Beandefinitioninheritanceexample–inheritingfactorymethodconfiguration

Childbeandefinitionscanusebeandefinitioninheritancetoinheritfactorymethodconfigurationfromthe

parentbeandefinition.Let’slookatanexamplethatshowsfactorymethodconfigurationsareinheritedby

childbeandefinitions.

ThefollowingControllerFactoryclassdefinesagetControllerinstancefactorymethod:

Examplelisting3-5–ControllerFactoryclass

Project–ch03-bankapp-inheritance-examples

Sourcelocation-src/main/java/sample/spring/chapter03/bankapp/controller



packagesample.spring.chapter03.bankapp.controller;



publicclassControllerFactory{



publicObjectgetController(StringcontrollerName){

Objectcontroller=null;

if("fixedDepositController".equalsIgnoreCase(controllerName)){

controller=newFixedDepositControllerImpl();

}

if("personalBankingController".equalsIgnoreCase(controllerName)){

controller=newPersonalBankingControllerImpl();

}

returncontroller;

}

}

The above example listing shows that the getController factory method creates an instance of

FixedDepositControllerImpl or PersonalBankingControllerImpl class, depending upon the value of the

controllerNameargumentpassedtoit.IfthevalueofcontrollerNameargumentisfixedDepositController,

thegetController methodcreates an instance ofFixedDepositControllerImpl class. And, if the value of

controllerNameargumentispersonalBankingController,thegetControllermethodcreatesaninstanceof

PersonalBankingControllerImplclass.

The following bean definitions inthe applicationContext.xml file of ch03-bankapp-inheritance-example

project show that the child bean definitions inherit the getController instance factory method

configurationfromtheparentbeandefinition:

Example listing 3-6 – applicationContext.xml - Bean definition inheritance – inheriting the factory

methodconfiguration

Project–ch03-bankapp-inheritance-examples

Sourcelocation-src/main/resources/META-INF/spring



<beanid="controllerFactory"

class="sample.spring.chapter03.bankapp.controller.ControllerFactory"/>



<beanid="controllerTemplate"factory-bean="controllerFactory"

factory-method="getController"abstract="true">

</bean>



<beanid="fixedDepositController"parent="controllerTemplate">

<constructor-argindex="0"value="fixedDepositController"/>

<propertyname=“fixedDepositService"ref="fixedDepositService"/>

</bean>



<beanid="personalBankingController"parent="controllerTemplate">

<constructor-argindex="0"value="personalBankingController"/>

<propertyname="personalBankingService"ref="personalBankingService"/>

</bean>

In the above example listing, the ControllerFactory class represents a factory class that defines a

getController instance factory method. The controllerTemplate bean definition specifies that the

ControllerFactory’sgetController factorymethodis used forcreatingbeaninstances.ThegetController

method (refer example listing 3-5) creates an instance of FixedDepositControllerImpl or

PersonalBankingControllerImplbean,dependingontheargumentpassedtothegetControllermethod.

As the controllerTemplate bean definition has been defined as abstract, it is up to the

fixedDepositController and personalBankingController child bean definitions to use the getController

factorymethodconfiguration.ThefixedDepositControllerbeandefinitionwouldliketopassanargument

to the ControllerFactory’s getController factory method so that it creates an instance of

FixedDepositControllerImplbean.And,personalBankingControllerbeandefinitionwouldliketopassan

argument to the ControllerFactory’s getController factory method so that it creates an instance of

PersonalBankingControllerImpl bean. We saw in section 2-3 of chapter 2 that the <constructor-arg>

element is used to pass an argument to an instance factory method. In example listing 3-6, the

<constructor-arg>elementhasbeenusedbyfixedDepositControllerandpersonalBankingControllerchild

beandefinitionstopass‘fixedDepositService’and‘personalBankingService’values,respectively,tothe

getControllerfactorymethod.

It is recommended that you now run the main method of BankApp class of ch03-bankapp-inheritance-

examplesprojecttoseeusageofthebeandefinitioninheritanceexamplesdiscussedinthissection.

Let’snowlookathowconstructorargumentsarematched.

3-3Constructorargumentmatching

Inthepreviouschapter,wesawthattheconstructorargumentsarespecifiedinthebeandefinitionsusing

the<constructor-arg>element.Inthissection,we’lllookathowSpringcontainermatchesaconstructor

argumentspecifiedbya<constructor-arg>elementtothecorrespondingconstructorargumentspecifiedin

thebeanclass’sconstructor.

Beforewegointothedetailsofconstructorargumentmatching,let’slookbackathowwepassarguments

toabeanclass’sconstructor.

IMPORT chapter 3/ch03-bankapp-constructor-args-by-type (This project shows the MyBank

application in which bean class’s constructor arguments are matched by type (explained later in this

section).Toruntheapplication,executethemainmethodoftheBankAppclassofthisproject)

Passingsimplevaluesandbeanreferencesusing<constructor-arg>element

If a constructor argument is of simple Java type (like int, String, and so on), the <constructor-arg>

element’svalueattributeisusedtospecifythevalueoftheconstructorargument.Ifaconstructorargument

is a reference to a bean, you specify the name of the bean using the <constructor-arg> element’s ref

attribute.

ThefollowingexamplelistingshowstheUserRequestControllerImplclassofch03-bankapp-constructor-

args-by-typeprojectwhoseconstructoracceptsanargumentoftypeServiceTemplate:

Examplelisting3-7–UserRequestControllerImplclass

Project–ch03-bankapp-constructor-args-by-type

Sourcelocation-src/main/java/sample/spring/chapter03/bankapp/controller



packagesample.spring.chapter03.bankapp.controller;



publicclassUserRequestControllerImplimplementsUserRequestController{

privateServiceTemplateserviceTemplate;



publicUserRequestControllerImpl(ServiceTemplateserviceTemplate){

this.serviceTemplate=serviceTemplate;

}



@Override

publicvoidsubmitRequest(Requestrequest){

//--dosomethingusingServiceTemplate

serviceTemplate.getJmsMessageSender();//--Forex.,sendJMSmessage

.....

}

}

The following example listing shows that a reference to ServiceTemplate instance (represented by

serviceTemplatebeandefinition)ispassedtoUserRequestControllerImpl’sconstructorusingrefattribute

of<constructor-arg>element:

Example listing 3-8 – applicationContext.xml - Passing reference to a Spring bean as constructor

argument

Project–ch03-bankapp-constructor-args-by-type

Sourcelocation-src/main/resources/META-INF/spring



<beanid="serviceTemplate"class="sample.spring.chapter03.bankapp.base.ServiceTemplate">

.....

</bean>



<beanid="userRequestController"

class="sample.spring.chapter03.bankapp.controller.UserRequestControllerImpl">

<constructor-argindex="0"ref="serviceTemplate"/>

</bean>

With this background information on how to pass simple values and bean references as constructor

arguments,let’snowlookathowSpringcontainermatchesconstructorargumenttypestolocatethebean’s

constructortobeinvoked.

Constructorargumentmatchingbasedontype

Ifthe<constructor-arg>element’sindexattributeisnotspecified,Springcontainerlocatestheconstructor

tobeinvokedbymatchingthetypesreferencedbythe<constructor-arg>elementswiththeargumenttypes

specifiedinthebeanclass’sconstructor(s).

Let’sfirstlookathowSpringcontainermatchesconstructorargumentswhentheconstructorargumentsare

Springbeansthatarenotrelatedbyinheritance.

ConstructorargumentsrepresentingdistinctSpringbeans

The following example listing shows the ServiceTemplate class that defines a constructor that accepts

referencestoJmsMessageSender,EmailMessageSenderandWebServiceInvokerbeans:

Examplelisting3-9–ServiceTemplateclass

Project–ch03-bankapp-constructor-args-by-type

Sourcelocation-src/main/java/sample/spring/chapter03/bankapp/base



packagesample.spring.chapter03.bankapp.base;



publicclassServiceTemplate{

.....

publicServiceTemplate(JmsMessageSenderjmsMessageSender,

EmailMessageSenderemailMessageSender,

WebServiceInvokerwebServiceInvoker){

.....

}

}

The following example listing shows the bean definitions for the ServiceTemplate class and the beans

referencedbyServiceTemplate:

Examplelisting3-10–applicationContext.xml-BeandefinitionfortheServiceTemplate class and its

dependencies

Project–ch03-bankapp-constructor-args-by-type

Sourcelocation-src/main/resources/META-INF/spring



<beanid="serviceTemplate"class="sample.spring.chapter03.bankapp.base.ServiceTemplate">

<constructor-argref="emailMessageSender"/>

<constructor-argref="jmsMessageSender"/>

<constructor-argref="webServiceInvoker"/>

</bean>



<beanid="jmsMessageSender"class="sample.spring.chapter03.bankapp.base.JmsMessageSender"/>

<bean id="emailMessageSender" class="sample.spring.chapter03.bankapp.base.EmailMessageSender"

<beanid="webServiceInvoker"class="sample.spring.chapter03.bankapp.base.WebServiceInvoker"/>

Intheaboveexamplelisting,the<constructor-arg>elementsofserviceTemplatebeandon’tspecifythe

index attribute. The order in which the constructor arguments are specified by  the <constructor-arg>

elements is: EmailMessageSender, JmsMessageSender, WebServiceInvoker. The order in which

constructor arguments are specified in the ServiceTemplate class’s constructor is: JmsMessageSender,

EmailMessageSender,WebServiceInvoker.Asyoucansee,theorderinwhichconstructorargumentsare

definedbythe<constructor-arg>elementsisdifferentfromtheorderspecifiedbytheServiceTemplate

class’sconstructor.

If you execute the main method of BankApp class of ch03-bankapp-constructor-args-by-type project,

you’ll find that the Spring container successfully creates an instance of ServiceTemplate bean. This is

becauseJmsMessageSender,EmailMessageSenderandWebServiceInvokerclassesaredistinctinnature

(thatis,theyarenotrelatedbyinheritance),whichmakesiteasierfortheSpringcontainertoinjecttheir

instancesintotheServiceTemplateclass’sconstructorinthecorrectorder.

Iftheconstructorargumenttypesarerelatedbyinheritance,Springcontainerneedsextrainstructionsto

help resolve constructor arguments. Let’s now look at how Spring container matches constructor

argumentswhenbeansreferencedbytheconstructorargumentsarerelatedbyinheritance.

ConstructorargumentsrepresentingrelatedSpringbeans

ConsiderthefollowingSampleBeanbeanclasswhoseconstructoracceptsargumenttypesthatarerelated

byinheritance:

Examplelisting3-11–SampleBeanclass

publicclassSampleBean{

publicSampleBean(ABeanaBean,BBeanbBean){.....}

.....

}

The above example listing shows that the SampleBean class’s constructor accepts ABean and BBean

typesasarguments.ABeanandBBeanrepresentSpringbeansthatarerelatedbyinheritance;BBeanisa

subclassofABean.

The following application context XML file shows the bean definitions for SampleBean, ABean and

BBeanclasses:



Examplelisting3-12–BeandefinitionsforSampleBean,ABeanandBBeanclasses

<beanid="aBean"class="example.ABean"/>

<beanid="bBean"class="example.BBean"/>



<beanid="sampleBean"class="example.SampleBean">

<constructor-argref="bBean"/>

<constructor-argref="aBean"/>

</bean>

AsaBeanandbBeanbeansarerelatedbyinheritance,Springcontainerappliesconstructorargumentsto

the SampleBean’s constructor in the order in which <constructor-arg> elements appear in the bean

definitionfortheSampleBeanclass.IntheabovesampleBeanbeandefinition,thefirst<constructor-arg>

elementreferstobBeanbeanandthesecond<constructor-arg>elementreferstoaBeanbean.Thismeans

that bBean is passed as the first constructor argument and aBean is passed as the second constructor

argumenttotheSampleBeanconstructor.AsinstanceofABean(thesuperclass)can’t bepassedwhere

BBean(thesubclass)instanceisexpected,thesecond<constructor-arg>elementinthesampleBeanbean

definitionresultsinexceptionbeingthrownbytheSpringcontainer.Tohandlesuchscenarios,youcan

use <constructor-arg> element’s index or type attribute to identify the constructor argument to which

<constructor-arg>elementapplies.Forinstance,thefollowingsampleBeanbeandefinitionmakesuseof

type attribute to indicate the type of the constructor argument to which the <constructor-arg> element

applies:

Examplelisting3-13 –<constructor-arg> element’stype attribute identifies the type of the constructor

argument

<beanid="sampleBean"class="example.SampleBean">

<constructor-argtype="sample.spring.chapter03.bankapp.controller.BBean"ref="bBean"/>

<constructor-argtype="sample.spring.chapter03.bankapp.controller.ABean"ref="aBean"/>

</bean>

The<constructor-arg>element’stypeattributespecifiesthefully-qualifiednameofthetypetowhichthe

<constructor-arg>elementapplies.Intheaboveexamplelisting,thefirst<constructor-arg>appliestothe

constructorargumentoftypeBBean,andthesecond<constructor-arg>elementappliestotheconstructor

argument of type ABean. Specifying the type attribute takes away the ambiguity that arises when

constructorargumentsarerelatedbyinheritance.

NOTEIftwoormoreconstructorargumentsareofthesametype,theonlyoptionistouseindex

attributetoidentifytheconstructorargumenttowhicheach<constructor-arg>elementapplies.



Sofarwehavelookedatconstructorargumenttypematchingscenariosinwhichconstructorarguments

represented distinct or related Spring beans. We’ll now look at how constructor argument types are

matchedforstandardJavatypes(likeint,long,boolean,String,Date,andsoon)andcustomtypes.

ConstructorargumentsrepresentingstandardJavatypesandcustomtypes

Ifthetypeofaconstructorargumentisaprimitivetype(likeint,long,boolean,andsoon)oraStringtype

or a custom type (like Address), the <constructor-arg> element’s value attribute is used to specify the

value. If there are 2 or more constructor arguments into which the string value specified by the value

attributecanbeconverted,it’llnotbepossiblefortheSpringcontainertoderivethetype(forexample,

whetherthevaluerepresentsanintorlongorString)oftheconstructorargument.Insuchscenarios,you

needtoexplicitlyspecifythetypeoftheconstructorargumentusingthetypeattribute.

ThefollowingexamplelistingshowstheTransferFundsServiceImplclassthatdefinesaconstructorwhich

acceptsargumentsoftypesString,boolean,longandint:

Examplelisting3-14–TransferFundsServiceImplclass

Project–ch03-bankapp-constructor-args-by-type

Sourcelocation-src/main/java/sample/spring/chapter03/bankapp/service



packagesample.spring.chapter03.bankapp.service;



publicclassTransferFundsServiceImplimplementsTransferFundsService{

publicTransferFundsServiceImpl(StringwebServiceUrl,booleanactive,longtimeout,

intnumberOfRetrialAttempts){.....}

.....

}

As the above example listing shows, TransferFundsServiceImpl constructor accepts the following

arguments:webServiceUrl,active,timeoutandnumberOfRetrialAttempts.Thefollowingbeandefinition

for the TransferFundsServiceImpl class shows how constructor argument values can be passed to the

TransferFundsServiceImpl’sconstructor:

Examplelisting3-15–BeandefinitionfortheTransferFundsServiceImplclass



<beanid="transferFundsService"

class="sample.spring.chapter03.bankapp.service.TransferFundsServiceImpl">

<constructor-argvalue="http://someUrl.com/xyz"/>

<constructor-argvalue="true"/>

<constructor-argvalue="5"/>

<constructor-argvalue="200"/>

</bean>

Let’sassumethatthe3rd<constructor-arg>element(valueattribute’svalueis‘5’)issupposedtosupply

valueforthenumberOfRetrialAttemptsconstructorargument,andthe4th<constructor-arg>element(value

attribute’s value is ‘200’) is supposed to supply value for the timeout constructor argument. Spring

containerapplies<constructor-arg>elementstotheTransferFundsServiceImpl’sconstructorintheorder

inwhich<constructor-arg>elementsappearinthetransferFundsServicebeandefinition.Thismeansthat

the 3rd <constructor-arg> element applies to timeout argument, and the 4th <constructor-arg> element

appliestonumberOfRetrialAttemptsargument.Tohandlesuchambiguities,youcanspecifythetypeofa

constructorargumentvia<constructor-arg>element’stypeattribute,asshowninthefollowingexample

listing:

Examplelisting3-16–applicationContext.xml-<constructor-arg>element’stypeattribute

Project–ch03-bankapp-constructor-args-by-type

Sourcelocation-src/main/resources/META-INF/spring



<beanid="transferFundsService"

class="sample.spring.chapter03.bankapp.service.TransferFundsServiceImpl">

<constructor-argtype="java.lang.String"value="http://someUrl.com/xyz"/>

<constructor-argtype="boolean"value="true"/>

<constructor-argtype="int"value="5"/>

<constructor-argtype="long"value="200"/>

</bean>

IntheabovebeandefinitionfortheTransferFundsServiceImplclass,typeattributeisusedtospecifythe

constructor argument type. Spring container can now use type matching to correctly apply constructor

arguments.

NOTEIftwoormoreconstructorargumentsareofthesametype,theonlyoptionistouseindexattribute

foridentifyingtheconstructorargumenttowhicheach<constructor-arg>elementapplies.

Inthissection,wesawhowtypematchingisperformedbySpringtoresolveconstructorarguments.Let’s

nowlookathowyoucaninstructSpringtoperformconstructorargumentmatchingbasedonconstructor

argument’sname.

IMPORT chapter 3/ch03-bankapp-constructor-args-by-name (This project shows the MyBank

application in which bean class’s constructor arguments are matched byname.To run the application,

executethemainmethodoftheBankAppclassofthisproject)

Constructorargumentmatchingbasedonname

The <constructor-arg> element’s name attribute is used for specifying the name of the constructor

argument to which the <constructor-arg> element applies. The following example listing shows once

againtheTransferFundsServiceImplclasswhoseconstructoracceptsmultiplearguments:

Examplelisting3-17–TransferFundsServiceImplclass

Project–ch03-bankapp-constructor-args-by-name

Sourcelocation-src/main/java/sample/spring/chapter03/bankapp/service



packagesample.spring.chapter03.bankapp.service;



publicclassTransferFundsServiceImplimplementsTransferFundsService{

.....

publicTransferFundsServiceImpl(StringwebServiceUrl,booleanactive,longtimeout,

intnumberOfRetrialAttempts){.....}

}



The above example listing shows that the names of the constructor arguments defined by

TransferFundsServiceImpl’s constructor are: webServiceUrl, active, timeout and

numberOfRetrialAttempts.

NOTETheTransferFundsServiceImplclass’sconstructoracceptsargumentsthataresimpleJavatypes

(like,int,long,boolean,String,andsoon),buttheconceptexplainedinthissectionalsoappliesto

scenariosinwhichconstructorargumentsarereferencestoSpringbeans.



ThefollowingbeandefinitionfortheTransferFundsServiceImplclassuses<constructor-arg>element’s

name attribute to specify the name of the constructor argument to which the <constructor-arg> element

applies:

Examplelisting3-18–applicationContext.xml-<constructor-arg>element’snameattribute

Project–ch03-bankapp-constructor-args-by-name

Sourcelocation-src/main/resources/META-INF/spring



<beanid="transferFundsService"

class="sample.spring.chapter03.bankapp.service.TransferFundsServiceImpl">



<constructor-argname="webServiceUrl"value="http://someUrl.com/xyz"/>

<constructor-argname="active"value="true"/>

<constructor-argname="numberOfRetrialAttempts"value="5"/>

<constructor-argname="timeout"value="200"/>

</bean>



TheaboveconfigurationwillworkonlyifTransferFundsServiceImplclassiscompiledwithdebugflag

enabled(referto-goptionofjavac).Whenthedebugflagisenabled,namesofconstructorargumentsare

preserved in the generated .class file. If you don’t compile your classes with debug flag enabled, the

constructorargumentnamesarelostduringcompilation,andSpringhasnowaytolocatetheconstructor

argument corresponding to the constructor argument name specified by the <constructor-arg> element’s

nameattribute.

Ifyoudon’twanttocompileyourclassesusingdebugflagenabled,youcanuse@ConstructorProperties

annotation(introducedinJavaSE6)toclearlyspelloutnamesoftheconstructorarguments,asshown

hereforTransferFundsServiceImplclass:

Examplelisting3-19–@ConstructorPropertiesannotation

Project–ch03-bankapp-constructor-args-by-name

Sourcelocation-src/main/java/sample/spring/chapter03/bankapp/service



packagesample.spring.chapter03.bankapp.service;



importjava.beans.ConstructorProperties;



publicclassTransferFundsServiceImplimplementsTransferFundsService{



@ConstructorProperties({"webServiceUrl","active","timeout","numberOfRetrialAttempts"})

publicTransferFundsServiceImpl(StringwebServiceUrl,booleanactive,longtimeout,

intnumberOfRetrialAttempts){.....}

}

In the above example listing, @ConstructorProperties annotation specifies the names of constructor

argumentsintheorderinwhichtheyappearinthebeanclass’sconstructor.Youmustensurethatyouuse

thesameconstructorargumentnamesinthe<constructor-arg>elements.

Let’snowlookathowthe@ConstructorPropertiesannotationaffectsbeandefinitioninheritance.

@ConstructorPropertiesannotationandbeandefinitioninheritance

If the constructor of the class corresponding to the parent bean definition is annotated with

@ConstructorPropertiesannotation,thebeanclasscorrespondingtothechildbeandefinitionmustalso

beannotatedwith@ConstructorPropertiesannotation.

The following example listing shows the serviceTemplate (parent bean definition) and

FixedDepositService(childbeandefinition)beandefinitions:

Examplelisting3-20–applicationContext.xml-Parentandchildbeandefinitions

Project–ch03-bankapp-constructor-args-by-name

Sourcelocation-src/main/resources/META-INF/spring

<beanid="serviceTemplate"

class="sample.spring.chapter03.bankapp.base.ServiceTemplate">

<constructor-argname="emailMessageSender"ref="emailMessageSender"/>

<constructor-argname="jmsMessageSender"ref="jmsMessageSender"/>

<constructor-argname="webServiceInvoker"ref="webServiceInvoker"/>

</bean>



<beanid="FixedDepositService"

class="sample.spring.chapter03.bankapp.service.FixedDepositServiceImpl"

parent="serviceTemplate">

<propertyname=“fixedDepositDao"ref="FixedDepositDao"/>

</bean>

TheaboveexamplelistingshowsthattheserviceTemplatebeandefinitionisnotabstract,whichmeans

that the Spring container will create an instance of serviceTemplate bean. The serviceTemplate bean

definition specifies 3 <constructor-arg> elements, corresponding to the 3 arguments defined by the

ServiceTemplateclass(referexamplelisting3-21).Aswehavespecifiedconstructorargumentsbyname

in the serviceTemplate bean definition, the ServiceTemplate class’s constructor is annotated with the

@ConstructorPropertiesannotationtoensurethatconstructorargumentnamesareavailabletoSpringat

runtime,asshownhere:

Examplelisting3-21–ServiceTemplateclass

Project–ch03-bankapp-constructor-args-by-name

Sourcelocation-src/main/java/sample/spring/chapter03/bankapp/base



packagesample.spring.chapter03.bankapp.base;



importjava.beans.ConstructorProperties;



publicclassServiceTemplate{

.....

@ConstructorProperties({"jmsMessageSender","emailMessageSender","webServiceInvoker"})

publicServiceTemplate(JmsMessageSenderjmsMessageSender,

EmailMessageSenderemailMessageSender,

WebServiceInvokerwebServiceInvoker){.....}

}

As FixedDepositService is a child bean definition of serviceTemplate, the <constructor-arg>

configurationinserviceTemplatebeandefinitionisinheritedbytheFixedDepositServicebeandefinition.

ThismeansthattheFixedDepositServiceImplclassmustdefineaconstructorthatacceptsthesamesetof

arguments as defined by the ServiceTemplate class, and it must also be annotated with

@ConstructorProperties annotation. If you don’t annotate FixedDepositServiceImpl’s constructor with

@ConstructorPropertiesannotation,Springcontainerwillnotbeabletomatchtheinherited<constructor-

arg>elementswiththeconstructorargumentsspecifiedintheFixedDepositServiceImpl’sconstructor.

Youcan’tuse@ConstructorPropertiesannotationforpassingargumentsbynametoastaticorinstance

factorymethod,asexplainednext.

@ConstructorPropertiesannotationandfactorymethods

We saw in section 2-3 of chapter 2 that the <constructor-arg> elements are also used for passing

argumentstostaticandinstancefactorymethods.Youmightthinkthatyoucanpassargumentsbynameto

static and instance factory methods by specifying the <constructor-arg> element’s name attribute and

annotating the factory method with @ConstructorProperties annotation. You should note that

@ConstructorProperties annotation is meant only for constructors; you can’t annotate methods with

@ConstructorProperties annotation. So, if you want to pass arguments by name to a static or instance

factorymethod,theonlyoptionyouhaveistocompileclasseswithdebugflagenabled.

NOTEIfyoucompileclasseswithdebugflagenabled,itresultsin.classfilesthatarelargerinsize,but

hasnoimpactontheruntimeperformanceoftheapplication.Itonlyresultsinincreasedloadingtimefor

theclasses.



Let’snowlookathowtoenableordisabledebugflaginEclipseIDE.

Enabling(ordisabling)thedebugflaginEclipseIDE

InEclipseIDE,followthesestepstoenablethedebugflagforprojects:

1.GotoWindowsàPreferencesandselecttheoptionJavaàCompiler

2.You’llnowseeasectiontitled‘ClassfileGeneration’.Inthissection,ifyoucheckthecheckbox

labeled‘Addvariableattributestogeneratedclassfiles(usedbythedebugger)’,thedebugflagis

enabled.Uncheckingthischeckboxwilldisablethedebugflag.

Sofarwehavemostlyseenbeandefinitionexamplesinwhichbeanpropertiesandconstructorarguments

werereferencestootherbeans.We’llnowlookatbeandefinitionexamplesinwhichbeanpropertiesand

constructorargumentsareofprimitivetype,collectiontype,java.util.Date,java.util.Properties,andsoon.

3-4 Configuring different types of bean properties and constructor

arguments

Inrealworldapplicationdevelopmentscenarios,propertiesandconstructorargumentsofaSpringbean

could range from a String type to reference to another bean to any other standard (like java.util.Date,

java.util.Map)orcustom(likeAddress)type.Sofarwehaveseenexamplesofhowtosupplyvaluefor

String type bean properties (using value attribute of <property> element) and String type constructor

arguments (using value attribute of <constructor-arg> element). We also looked at how to inject

dependenciesviabeanproperties(usingrefattributeof<property>element)andconstructorarguments

(usingrefattributeof<constructor-arg>elements).

Inthissection,we’lllookatbuilt-inPropertyEditorimplementationsinSpringthatsimplifypassingbean

properties and constructor arguments of types java.util.Date, java.util.Currency, primitive type, and so

on.We’llalsolookathowtospecifyvaluesforcollectiontypes(likejava.util.Listandjava.util.Map)in

the application context XML file, and how to register a custom PropertyEditor implementation with

Spring.

Let’s now look at bean definition examples that demonstrate use of built-in PropertyEditor

implementations.

IMPORT chapter 3/ch03-simple-types-examples (This project shows a Spring application in which

bean properties and constructor arguments are of primitive type, java.util.Date, java.util.List,

java.util.Map, and so on. This project also shows how to register a custom PropertyEditor

implementationwithSpringcontainer.Toruntheapplication,executethemainmethodoftheSampleApp

classofthisproject)

Built-inpropertyeditorsinSpring

JavaBeansPropertyEditorsprovidethenecessarylogicforconvertingaJavatypetoastringvalue,and

viceversa.Springprovidesacoupleofbuilt-inPropertyEditorsthatareusedforconvertingstringvalue

of a bean property or a constructor argument (specified via value attribute of <property> and

<constructor-arg>elements)totheactualJavatypeofthepropertyorconstructorargument.

Beforewelookat examples involvingbuilt-inPropertyEditors,let’s firstunderstand the importance of

PropertyEditorsinsettingvaluesofbeanpropertiesorconstructorarguments.

ConsiderthefollowingBankDetailsclassthatwewanttoconfigureasasingleton-scopedbeanwithpre-

definedvaluesforitsattributes:

Examplelisting3-22–BankDetailsclass



publicclassBankDetails{

privateStringbankName;



publicvoidsetBankName(StringbankName){

this.bankName=bankName;

}

}

Intheaboveexamplelisting,bankNameisanattributeoftheBankDetailsclass,andisoftypeString.The

followingbeandefinitionfortheBankDetailsclassshowshowtosetthevalueofbankNameattributeto

‘MyPersonalBank’:

Examplelisting3-23–BeandefinitionfortheBankDetailsclass



<beanid="bankDetails"class="BankDetails">

<propertyname="bankName"value="MyPersonalBank"/>

</bean>

In the above bean definition, the <property> element’s value attribute specifies a string value for the

bankNameproperty.Asyoucansee,ifabeanpropertyisoftypeString,youcansimplysetthatproperty

valueusing<property> element’s value attribute. Similarly, if a constructor argument is of type String,

youcansettheconstructorargumentvalueusing<constructor-arg>element’svalueattribute.

Let’ssaythatthefollowingattributes(alongwiththeirsettermethods)areaddedtotheBankDetailsclass:

a bankPrimaryBusiness attribute of type byte[], a headOfficeAddress attribute of type char[], a

privateBank attribute of type char, a primaryCurrency attribute of type java.util.Currency, a

dateOfInception attribute of type java.util.Date, and a branchAddresses attribute of type

java.util.Properties.ThefollowingexamplelistingshowsthemodifiedBankDetailsclass:

Examplelisting3-24–BankDetailsclasscontainingdifferenttypesofproperties

Project–ch03-simple-types-examples

Sourcelocation-src/main/java/sample/spring/chapter03/beans



packagesample.spring.chapter03.beans;

.....

publicclassBankDetails{

privateStringbankName;

privatebyte[]bankPrimaryBusiness;

privatechar[]headOfficeAddress;

privatecharprivateBank;

privateCurrencyprimaryCurrency;

privateDatedateOfInception;

privatePropertiesbranchAddresses;

.....

publicvoidsetBankName(StringbankName){

this.bankName=bankName;

}

//--moresettermethods

}

YoucanconfiguretheBankDetailsclassasaSpringbeanbyspecifyingstringvaluesfortheproperties,

and letting the Spring container convert these string values into the corresponding Java types of the

propertiesbyusingregisteredJavaBeansPropertyEditorimplementations.

ThefollowingbeandefinitionfortheBankDetailsclassshowsthatsimplestringvaluesarespecifiedfor

differentpropertytypes:

Examplelisting3-25–applicationContext.xml-BeandefinitionfortheBankDetailsclass

Project–ch03-simple-types-examples

Sourcelocation-src/main/resources/META-INF/spring

<beanid="bankDetails"class="sample.spring.chapter03.beans.BankDetails">

<propertyname="bankName"value="MyPersonalBank"/>

<propertyname="bankPrimaryBusiness"value="Retailbanking"/>

<propertyname="headOfficeAddress"value="Addressofheadoffice"/>

<propertyname="privateBank"value="Y"/>

<propertyname="primaryCurrency"value="INR"/>

<propertyname="dateOfInception"value="30-01-2012"></property>

<propertyname="branchAddresses">

<value>

x=BranchX'saddress

y=BranchY'saddress

</value>

</property>

</bean>

Theaboveexamplelistingshows thatstring valuesarespecifiedforpropertiesoftypesjava.util.Date,

java.util.Currency, char[], byte[], char and java.util.Properties. Spring container uses registered

PropertyEditors for converting the string value of the property or constructor argument to the

correspondingJavatypeofthepropertyorconstructorargument.Forinstance,Springcontainerconverts

the value ‘30-01-2012’ of dateOfInception property to java.util.Date type using CustomDateEditor (a

built-inPropertyEditorimplementationforjava.util.Datetype).

If you look at how branchAddresses property (of type java.util.Properties) is configured in example

listing 3-25, you’ll notice that instead of <property> element’s value attribute, <value> sub-element of

<property> element has been used to specify the value for the property. In case of single-valued

properties,theuseof<property>element’svalueattributeispreferredover<value>sub-element.But,if

youneedtospecifymultiplevaluesforapropertyorthevaluesneedtobespecifiedonseparatelines(as

inthecaseofbranchAddressesproperty),the<value>sub-elementispreferredovervalueattribute.In

the next section, you’ll see that values for properties (or constructor arguments) of type

java.util.Properties can also be specified using <props> sub-element of <property> ( or <constructor-

arg>)element.

Springcomeswithcoupleofbuilt-inPropertyEditorimplementationsthatperformthetaskofconverting

valuesspecifiedintheapplicationcontextXMLfiletotheJavatypeofthebeanpropertyorconstructor

argument.Thefollowingtabledescribessomeofthebuilt-inPropertyEditorimplementationsinSpring:

Built-in PropertyEditor

implementation Description

CustomBooleanEditor convertsstringvaluetoBooleanorbooleantype

CustomNumberEditor convertsstringvaluetoanumber(likeint,long,andsoon)

ChracterEditor convertsstringvaluetochartype

ByteArrayPropertyEditor convertsstringvaluetobyte[]

CustomDateEditor convertsstringvaluetojava.util.Datetype

PropertiesEditor convertsstringvaluetojava.util.Propertiestype



Theabovetableshowsonlyasubsetofbuilt-inPropertyEditorimplementationsinSpring.Foracomplete

list,refertotheorg.springframework.beans.propertyeditorspackageofSpring.Itisimportanttonotethat

not all built-in PropertyEditor implementations in Spring are registered with the Spring container by

default. For instance, you need to explicitly register CustomDateEditor to allow Spring container to

performconversionfromastringvaluetoajava.util.Datetype.Laterinthissection,we’lllookathow

youcanregisterpropertyeditorswithSpringcontainer.

Let’s now look at how to specify values for bean properties (or constructor arguments) of types

java.util.List,java.util.Setandjava.util.Map.

Specifyingvaluesfordifferentcollectiontypes

The <list>, <map> and <set> sub-elements (defined in Spring’s beans schema) of <property> and

<constructor-arg> elements are used to set properties and constructor arguments of type java.util.List,

java.util.Mapandjava.util.Set,respectively.

NOTESpring’sutilschemaalsoprovides<list>,<set>and<map>elementsthatsimplifysetting

propertiesandconstructorargumentsofdifferentcollectiontypes.Laterinthischapter,we’lllookat

Spring’sutilschemaelementsindetail.

ThefollowingDataTypesExampleclassshowsthatitsconstructoracceptsargumentsofdifferenttypes:

Examplelisting3-26–DataTypesExampleclass

Project–ch03-simple-types-examples

Sourcelocation-src/main/java/sample/spring/chapter03/beans



packagesample.spring.chapter03.beans;



importjava.beans.ConstructorProperties;

.....

publicclassDataTypesExample{

privatestaticLoggerlogger=Logger.getLogger(DataTypesExample.class);



@SuppressWarnings("rawtypes")

@ConstructorProperties({"byteArrayType","charType","charArray",

"classType","currencyType","booleanType","dateType","longType",

"doubleType","propertiesType","listType","mapType","setType",

"anotherPropertiesType"})

publicDataTypesExample(byte[]byteArrayType,charcharType,

char[]charArray,ClassclassType,CurrencycurrencyType,

booleanbooleanType,DatedateType,longlongType,

doubledoubleType,PropertiespropertiesType,List<Integer>listType,

MapmapType,SetsetType,PropertiesanotherPropertiesType){

.....

logger.info("classType"+classType.getName());

logger.info("listType"+listType);

logger.info("mapType"+mapType);

logger.info("setType"+setType);

logger.info("anotherPropertiesType"+anotherPropertiesType);

}

}

The above example listing shows that the DataTypesExample class’s constructor accepts arguments of

typesjava.util.List,java.util.Map,java.util.Setandjava.util.Properties,andsoon,andlogsthevalueof

eachconstructorargument.

ThefollowingexamplelistingshowsthebeandefinitionfortheDataTypesExampleclass:

Examplelisting3-27–applicationContext.xml-BeandefinitionforDataTypesExampleclass

Project–ch03-simple-types-examples

Sourcelocation-src/main/resources/META-INF/spring

<beanid="dataTypes"class="sample.spring.chapter03.beans.DataTypesExample">

.....

<constructor-argname="anotherPropertiesType">

<props>

<propkey="book">GettingstartedwiththeSpringFramework</prop>

</props>

</constructor-arg>

<constructor-argname="listType"value-type="java.lang.Integer">

<list>

<value>1</value>

<value>2</value>

</list>

</constructor-arg>

<constructor-argname="mapType">

<map>

<entry>

<key>

<value>mapkey1</value>

</key>

<value>mapkey1’svalue</value>

</entry>

</map>

</constructor-arg>

<constructor-argname="setType">

<set>

<value>Element1</value>

<value>Element2</value>

</set>

</constructor-arg>

</bean>

Theaboveexamplelistingshows:

·        the value of anotherPropertiesType (of type java.util.Properties) is specified using the

<props>sub-elementof<constructor-arg>element.Each<prop>elementspecifiesakey-value

pair;thekeyattributespecifiesthekeyvalueandthecontentof<prop>elementisthevaluefor

thekey.Insteadofusing<props>element,youcanuse<value>sub-elementof<constructor-arg>

elementtospecifythevalueforanotherPropertiesTypeargument.

·thevalueoflistTypeconstructorargument(oftypejava.util.List)isspecifiedusingthe<list>

sub-element of <constructor-arg>. The <value> sub-elements of <list> element specify items

contained in the list. The <list> element’s value-type attribute specifies the Java type of the

elements that the java.util.List type constructor argument accepts. As the listType constructor

argumentisoftypeList<Integer>(referexamplelisting3-26),thevalue-typeattribute’svalueis

specifiedasjava.lang.Integer.Thevalue-typeattributeisoptional,andisparticularlyusefulif

you are using a parameterized List type, like List<Integer>. If you specify the value-type

attribute,Springcontainerusestheregisteredpropertyeditorstoperformconversionofvalues

tothetypespecifiedbythevalue-typeattribute,followedbyconverting(ifrequired)thevalues

tothetypeacceptedbytheparameterizedListtype.Ifyoudon’tspecifythevalue-typeattribute,

Springcontainersimplyusestheregisteredpropertyeditorstoperformconversionofvaluesto

thetypeacceptedbytheparameterizedListtype.

·thevalueofmapTypeconstructorargument(oftypejava.util.Map) is specified usingthe

<map>sub-elementof<constructor-arg>.The <entry>sub-elementof <map> specifies a key-

valuepaircontainedintheMap;the<key>elementspecifiesthekeyandthe<value>element

specifiesthevalueforthekey.Thekey-typeandvalue-typeattributesof<map>elementspecify

the Java type of keys and values that java.util.Map accepts. The key-type and value-type

attributes are optional, and especially useful if you are using parameterized Map type, like

Map<Integer,Integer>.Springcontainerusesregisteredpropertyeditorstoperformconversion

of keys and values to the types specified by the key-type and value-type attributes, and to the

typesacceptedbytheparameterizedMaptype.

·thevalueofthesetTypeconstructorargument(oftypejava.util.Set)isspecifiedusingthe

<set> sub-element of <constructor-arg>. Each <value> sub-element of <set> specifies an

elementcontainedintheSet.Thevalue-typeattributeof<set>elementspecifiestheJavatypeof

elementsthatjava.util.Setaccepts.Thevalue-typeattributeisoptional,andisusefulifyouare

using parameterized Set type, like Set<Integer>. Spring container uses registered property

editorstoperformconversionofvaluestothetypespecifiedbythevalue-typeattribute,andto

thetypeacceptedbytheparameterizedSettype.

InDataTypesExample class (refer example listing 3-26 and 3-27), constructor arguments of type List,

Map and Set contained elements of type String or Integer. In an application, a collection may contain

elements of type Map, Set, Class, Properties, or any other Java type. The elements contained in the

collectioncanalsobebeanreferences.Toaddresssuchscenarios,Springallowsyoutouseelementslike

<map>,<set>,<list>,<props>,<ref>,andsoon,assub-elementsof<list>,<map>and<set>elements.

Let’snowlookatexamplesthatdemonstratehowtoadddifferenttypesofelementstoMap,ListandSet

typeconstructorargumentsandbeanproperties.

AddingelementsoftypeList,Map,SetandPropertiestocollectiontypes

IfabeanpropertyorconstructorargumentisoftypeList<List>,simplyuseanested<list>element,as

shownhere:

Examplelisting3-28–Configurationexample:ListinsideaList



<constructor-argname="nestedList">

<list>

<list>

<value>AsimpleStringvalueinthenestedlist</value>

<value>AnothersimpleStringvalueinnestedlist</value>

</list>

</list>

</constructor-arg>

The <constructor-arg> element shown in the above example listing supplies value for a constructor

argumentnamednestedListwhichisoftypeList<List>.Thenested<list>elementrepresentsanelement

oftypeList.Similarly, you can use <map>,<set>and<props>elements inside a<list> element to set

value of properties or constructor arguments of type List<Map>, List<Set> and List<Properties>,

respectively.Aswiththe<list>element,a<set>elementcancontain<set>,<list>,<map>or<props>

element.Incaseofa<map>element,youcanuse<map>,<set>,<list>or<props>elementtospecifykey

andvalueofanentry.

ThefollowingexamplelistingshowshowyoucanspecifyvaluesforaMap<List,Set>typeconstructor

argument:

Examplelisting3-29–Configurationexample:MapcontainingListtypeaskeyandSettypeasvalue



<constructor-argname="nestedListAndSetMap">

<map>

<entry>

<key>

<list>

<value>aListelement</value>

</list>

</key>

<set>

<value>aSetelement</value>

</set>

</entry>

</map>

</constructor-arg>

The above example listing shows that the nestedListAndSetMap constructor argument is of Map type

whosekeyisoftypeListandvalueisoftypeSet.The<key>elementcanhaveeitherofthefollowing

elements as its sub-element: <map>,<set>,<list> and <props>. The value for the key can be defined

using<map>,<set>,<list>or<props>element.

Addingbeanreferencestocollectiontypes

Youcanuse<ref>elementsinside<list>and<set>elementstoaddreferencestobeansintoproperties

andconstructorargumentsoftypeListandSet,respectively.

The following example listing shows how references to beans are added to a List type constructor

argument:

Examplelisting3-30–Configurationexample:Listcontainingreferencetobeans

<bean.....>

<constructor-argname="myList">

<list>

<refbean="aBean"/>

<refbean="bBean"/>

</list>

</constructor-arg>

</bean>



<beanid="aBean"class="somepackage.ABean"/>

<beanid="bBean"class="somepackage.BBean"/>

Theaboveexamplelistingshows that the myList constructorargumentis of typeListand it contains 2

elements-areferencetoaBeanbeanandareferencetobBeanbean.The<ref>element’sbeanattribute

specifiesthenameofthebeanreferencedbythe<ref>element.

Aswiththe<list>element,youcanuse<ref>elementsinside<set>elementtoaddbeanreferencestoa

Set type constructor argument or bean property. In case of <map> element, you can use <ref> element

insidea<key>elementtospecifyabeanreferenceasakey,andusethe<ref>elementtospecifyabean

referenceasavalueforthekey.ThefollowingexamplelistingshowsaMaptypeconstructorargument

thatcontainsasinglekey-valuepairinwhichbothkeyandvaluearereferencestobeans:

Examplelisting3-31–Configurationexample:Mapcontainingbeanreferencesaskeysandvalues

<bean.....>

<constructor-argname="myMapWithBeanRef">

<map>

<entry>

<key>

<refbean="aBean"/>

</key>

<refbean="bBean"/>

</entry>

</map>

</constructor-arg>

</bean>



<beanid="aBean"class="somepackage.ABean"/>

<beanid="bBean"class="somepackage.BBean"/>

The above example listing shows that myMapWithBeanRef constructor argument is of type Map and it

contains a key-value pair in which the key is a reference to aBean bean and corresponding value is a

referencetobBeanbean.

Addingbeannamestocollectiontypes

Ifyouwanttoaddabeanname(asspecifiedbytheidattributeof<bean>element)toaList,MaporSet

type constructor argument or bean property, you can use the <idref>element inside <map>, <set> and

<list> elements. The following example listing shows a Map type constructor argument that contains a

singlekey-valuepair,wherebeannameisthekeyandbeanreferenceisthevalue:

Examplelisting3-32–Configurationexample:Mapcontainingbeannameaskeyandbeanreferenceas

value

<constructor-argname="myExample">

<map>

<entry>

<key>

<idrefbean="sampleBean"/>

</key>

<refbean="sampleBean"/>

</entry>

</map>

</constructor-arg>



<beanid="sampleBean"class="somepackage.SampleBean"/>

TheaboveexamplelistingshowsthatthemyExampleconstructorargumentisoftypeMapwhosekeyis

thestringvalue‘sampleBean’andvalueisthesampleBeanbean.Wecouldhaveused<value>elementto

set‘sampleBean’stringvalueasthekey,but<idref>elementisusedbecauseSpringcontainerverifies

existenceofthesampleBeanbeanwhentheapplicationisdeployed.

NOTEYoucanusethe<idref>elementinsidea<property>or<constructor-arg>elementtosetabean

nameasthevalueofabeanpropertyorconstructorargument.

Addingnullvaluestocollectiontypes

YoucanaddanullvaluetocollectionsoftypeSetandListusing<null>element.Thefollowingexample

listingshowshowtoaddanullvaluetoaSettypeconstructorargumentusing<null>element:

Examplelisting3-33–Configurationexample:Setcontaininganullelement

<constructor-argname="setWithNullElement">

<set>

<value>Element1</value>

<value>Element2</value>

<null/>

</set>

</constructor-arg>

Intheaboveexamplelisting,setWithNullElementconstructorargumentcontains3elements:Element1,

Element2andnull.

ToaddanullkeytoaMaptypeconstructorargumentorproperty,youcanuse<null>elementinsidethe

<key>element.And,toaddanullvalue,youcanadda<null>elementinsidethe<entry>element.The

following example listing shows a Map type constructor argument that contains a null key and a null

value:

Examplelisting3-34–Configurationexample:Mapcontaininganullkeyandanullvalue

<constructor-argname="mapType">

<map>

<entry>

<key>

<null/>

</key>

<null/>

</entry>

</map>

</constructor-arg>

TheaboveexamplelistingshowsthatanelementwithnullkeyandnullvalueisaddedtothemapType

constructorargumentusing<null>element.

NOTEYoucanalsouse<null>elementinside<property>and<constructor-arg>elementstosetnull

valuesforpropertiesandconstructorarguments,respectively.

Let’snowlookathowtospecifyvaluesforarraytypepropertiesandconstructorarguments.

Specifyingvaluesforarrays

If a bean class defines an array type property, you can set its value using the <array> sub-element of

<property> element. Similarly, you can set an array type constructor argument using the <array> sub-

elementof<constructor-arg>element.

Thefollowingexamplelistingshowshowyoucansetabeanpropertyoftypeint[]:

Examplelisting3-35–Configurationexample:Settingvalueofabeanpropertyoftypeint[]

<propertyname="numbersProperty">

<array>

<value>1</value>

<value>2</value>

</array>

</property>

Intheaboveexamplelisting,each<value>sub-elementofthe<array>elementrepresentsanelementin

thenumbersPropertyarray.ThepropertyeditorsregisteredwiththeSpringcontainerareusedtoconvert

thestringvaluespecifiedbyeachofthe<value>elementtointtype.Youcanuse<array>elementinside

<list>,<set>and<map>elements.Youcanalsouse<list>,<set>,<map>,<props>and<ref>elements

insidean<array>elementtocreatearraysofList,Set,Map,Propertiesandbeanreferences,respectively.

Ifyouwanttocreateanarrayofarrays,youcanuse<array>elementsinsidean<array>element.

Wediscussedthat<list>,<map>and<set>elementsareusedtosetpropertiesorconstructorarguments

of type List, Map andSet, respectively. Let’s now look at the default collection implementation that is

createdbySpringforeachoftheseelements.

Defaultcollectionimplementationfor<list>,<set>and<map>elements

The following table shows the default collection implementation that is created by Spring for <list>,

<set>and<map>elements:

Collectionelement DefaultcollectionimplementationcreatedbyS pring

<list> java.util.ArrayList

<set> java.util.LinkedHashSet

<map> java.util.LinkedHashMap



Theabovetablesuggests:

·   if aproperty’s(or aconstructor argument’s) value is specified using <list> element, Spring

createsaninstanceofArrayListandassignsittotheproperty(ortheconstructorargument).

·     if a property’s (or a constructor argument’s) value is specified using <set> element, Spring

createsaninstanceofLinkedHashSetandassignsittotheproperty(ortheconstructorargument).

·ifaproperty’s(oraconstructorargument’s)valueisspecifiedusing<map>element,Spring

createsaninstanceofLinkedHashMapandassignsittotheproperty(ortheconstructorargument).

It is likely that you may want to substitute a different implementation of List, Set or Map to a bean

propertyoraconstructorargument.Forinstance,insteadofjava.util.ArrayList,youmaywanttoassignan

instanceofjava.util.LinkedListtoabeanpropertyoftypeList.Insuchscenarios,itisrecommendedto

use <list>, <map> and <set> elements of Spring’s util schema (explained in section 3-8). The <list>,

<set>and<map>elementsofSpring’sutilschemaprovidetheoptiontospecifythefully-qualifiedname

oftheconcretecollectionclassthatyouwanttoassigntothepropertyorconstructorargumentofthebean.

Let’snowlookatsomeofthebuilt-inpropertyeditorsprovidedbySpring.

3-5Built-inpropertyeditors

Spring provides a couple of built-in property editors that are useful when setting bean properties and

constructor arguments. Let’s take a quick look at CustomCollectionEditor, CustomMapEditor and

CustomDateEditorbuilt-inpropertyeditors.Toviewthecompletelistofbuilt-inpropertyeditors,referto

org.springframework.beans.propertyeditorspackage.

CustomCollectionEditor

CustomCollectionEditor property editor is responsible for converting a source Collection (like,

java.util.LinkedList) type to the target Collection (like, java.util.ArrayList) type. By default,

CustomCollectionEditorisregisteredforSet,SortedSetandListtypes.

Consider the following CollectionTypesExampleclass that defines attributes (and corresponding setter

methods)oftypeSetandList:

Examplelisting3-36–CollectionTypesExampleclass

Project–ch03-simple-types-examples

Sourcelocation-src/main/java/sample/spring/chapter03/beans



packagesample.spring.chapter03.beans;



importjava.util.List;

importjava.util.Set;



publicclassCollectionTypesExample{

privateSetsetType;

privateListlistType;

.....

//--settermethodsforattributes

publicvoidsetSetType(SetsetType){

this.setType=setType;

}

.....

}

CollectionTypesExampleclassdefinessetTypeandlistTypeattributesoftypeSetandList,respectively.

ThefollowingexamplelistingshowsthebeandefinitionforCollectionTypesExampleclass:

Examplelisting3-37–applicationContext.xml-BeandefinitionforCollectionTypesExampleclass

Project–ch03-simple-types-examples

Sourcelocation-src/main/resources/META-INF/spring

<beanclass="sample.spring.chapter03.beans.CollectionTypesExample">

<propertyname="listType">

<set>

<value>setelement1</value>

<value>setelement2</value>

</set>

</property>

<propertyname="setType">

<list>

<value>listelement1</value>

<value>listelement2</value>

</list>

</property>

.....

</bean>

Youmightthinkthattheaboveconfigurationisincorrectbecause<set>elementhasbeenusedtosetthe

valueoflistType property(of type List), and <list> element has been used to set the value of setType

property(oftypeSet).

Theaboveconfigurationiscompletelylegal,andtheSpringcontainerdoesnotcomplain.Thisisbecause

CustomCollectionEditor converts the ArrayList instance (created corresponding to the <list> type

element)toLinkedHashSettype(animplementationofSettype)beforesettingthesetTypeproperty.Also,

CustomCollectionEditorconverts the LinkedHashSet instance (created corresponding to the <set> type

element)toArrayListtype(animplementationofListtype)beforesettingthelistTypeproperty.

Figure3-4–CustomCollectionEditorconvertstheLinkedHashSettoArrayListtype

Figure3-4showsthattheCustomCollectionEditorconvertstheLinkedHashSettypetoArrayListtosetthe

value of CollectionTypesExample’slistType property. The figure shows the sequence of steps that are

performed by Spring to set the value of listType property. First, Spring creates an instance of

LinkedHashSetcorrespondingtothe<set>element.AsthelistTypepropertyisoftypeList(referexample

listing3-36),theCustomCollectionEditorcomesintopictureforsettingthelistTypeproperty’svalue.If

the type of the bean property is List, CustomCollectionEditor creates an instance of ArrayList and

populatesitwiththeelementsfromtheLinkedHashSet.Intheend,thevalueofthelistTypevariableisset

totheArrayListimplementationcreatedbyCustomCollectionEditor.

Itisimportanttonotethatifapropertyorconstructorargumenttypeisaconcretecollectionclass(like

LinkedList),CustomCollectionEditorsimplycreatesaninstanceoftheconcretecollectionclassandadds

elements to it from the source collection. The following figure shows a scenario in which the bean

propertyisoftypejava.util.Vector(aconcretecollectionclass):

Figure3-5CustomCollectionEditorconvertstheArrayListtoVectortype

The above figure shows that the CustomCollectionEditor creates an instance of Vector (a concrete

collectionclass)andaddselementstoitfromthesourcecollection,ArrayList.

Let’snowlookatCustomMapEditorpropertyeditor.

CustomMapEditor

CustomMapEditorpropertyeditordealswithconvertingasourceMaptype(likeHashMap) toa target

Maptype(likeTreeMap).Bydefault,CustomMapEditorisregisteredonlyforSortedMaptype.

Figure3-6showsascenarioinwhichCustomMapEditorconvertsLinkedHashMap(thesourceMaptype)

toTreeMap(animplementationofSortedMaptype).

Figure3-6showsthesequenceofstepsperformedbySpringtosetthevalueofmapTypeproperty.First,

Spring creates an instance of LinkedHashMap corresponding to the <map> element. As the mapType

propertyisoftypeSortedMap,CustomMapEditorcomesintopicturewhilesettingthevalueofmapType

property. CustomMapEditor creates an instance of TreeMap (a concrete implementation of SortedSet

interface),addskey-valuepairsfromLinkedHashMaptothenewlycreatedTreeMapinstanceandassigns

theTreeMapinstancetothemapTypeproperty.

Figure3-6CustomMapEditorconvertstheLinkedHashMap(thesourceMaptype)toTreeMap(thetarget

Maptype)type

CustomDateEditor

CustomDateEditorisapropertyeditorforjava.util.Datetypebeanpropertiesandconstructorarguments.

CustomDateEditorsupportsacustomjava.text.DateFormatthatisusedforformattingadate/timestringto

a java.util.Date type object, and parsing a java.util.Date type object to a date/time string. In the next

section,we’llseehowCustomDateEditorisusedforsettingbeanpropertiesandconstructorargumentsof

typejava.util.Date.In ch03-simple-types-examples project,CustomDateEditor converts the string value

ofabeanproperty(referdateOfInceptionattributeofBankDetailsclass)orconstructorargument(refer

dateTypeconstructorargumentofDataTypesExampleclass)tojava.util.Datetype.

Inch03-simple-types-examples project, some of the other built-in property editors that are utilized by

beans include: ByteArrayPropertyEditor - for converting a string value to byte[] (refer

bankPrimaryBusinessattributeofBankDetailsclass),CurrencyEditor–forconvertingacurrencycodeto

a java.util.Currency object (refer primaryCurrency attribute of BankDetails class),

CharacterArrayPropertyEditor – for converting a string value to a char[] (refer headOfficeAddress

attributeofBankDetailsclass),andsoon.

Let’snowlookathowtoregisterpropertyeditorswiththeSpringcontainer.

3-6RegisteringpropertyeditorswiththeSpringcontainer

Spring’sBeanWrapperImplclassregistersacoupleofbuilt-inpropertyeditorswiththeSpringcontainer.

Forinstance,CustomCollectionEditor,CustomMapEditor,CurrencyEditor,ByteArrayPropertyEditorand

CharacterArrayEditor property editors are registered by default with the Spring container. But,

CustomDateEditor property editor is not registered by default with the Spring container. To register

propertyeditorswith the Springcontainer,youcanuseSpring’s CustomEditorConfigurerspecial bean.

CustomEditorConfigurer class implements Spring’s BeanFactoryPostProcessor interface (explained in

detailinsection5-4ofchapter5),anditisautomaticallydetectedandexecutedbytheSpringcontainer.

In ch03-simple-types-examples project, BankDetails class (refer example listing 3-24) defines a

dateOfInceptionpropertyoftypejava.util.Date.ThevaluespecifiedforthedateOfInceptionpropertyis

‘30-01-2012’ (refer example listing 3-25). To convert the string value ‘30-01-2012’ to java.util.Date

type,youmustregisteracustompropertyeditorforjava.util.DatetypeoryoucanregisterSpring’sbuilt-

inCustomDateEditorpropertyeditorwiththeSpringcontainer.

ToregisterpropertyeditorswiththeSpringcontainer,youneedtodothefollowing:

1.    Create a class that implements Spring’s PropertyEditorRegistrar interface. This class is

responsibleforregisteringpropertyeditorswiththeSpringcontainer.

2.ConfigurethePropertyEditorRegistrarimplementationasaSpringbeanintheapplicationcontext

XMLfile.

3.ConfigureSpring’sCustomEditorConfigurerspecialbeanintheapplicationcontextXMLfile,and

provideitwithreferencetothePropertyEditorRegistrarimplementation(thatyoucreatedinstep1

andconfiguredinstep2).

Let’s now see how CustomDateEditor is registered with the Spring container in ch03-simple-types-

examplesproject.

CreatingaPropertyEditorRegistrarimplementation

The following example listing shows the MyPropertyEditorRegistrar class that implements

PropertyEditorRegistrarinterface:

Examplelisting3-38–MyPropertyEditorRegistrarclass

Project–ch03-simple-types-examples

Sourcelocation-src/main/java/sample/spring/chapter03/beans



packagesample.spring.chapter03.beans;



importjava.text.SimpleDateFormat;

importjava.util.Date;



importorg.springframework.beans.PropertyEditorRegistrar;

importorg.springframework.beans.PropertyEditorRegistry;

importorg.springframework.beans.propertyeditors.CustomDateEditor;



publicclassMyPropertyEditorRegistrarimplementsPropertyEditorRegistrar{



@Override

publicvoidregisterCustomEditors(PropertyEditorRegistryregistry){

registry.registerCustomEditor(Date.class,newCustomDateEditor(

newSimpleDateFormat("dd-MM-yyyy"),false));

}

}

The above example listing shows that the MyPropertyEditorRegistrar class implements Spring’s

PropertyEditorRegistrar interface, and provides implementation for registerCustomEditors method

defined in the PropertyEditorRegistrar interface. The PropertyEditorRegistry instance passed to the

registerCustomEditors method is used for registering property editors. PropertyEditorRegistry’s

registerCustomEditor method is used for registering a PropertyEditor implementation with the Spring

container. In the above example listing, PropertyEditorRegistry’s registerCustomEditor is used for

registeringaCustomDateEditorpropertyeditorwiththeSpringcontainer.

ConfiguringtheCustomEditorConfigurerclass

The following example listing shows how the CustomEditorConfigurer class is configured in the

applicationcontextXMLfile:

Examplelisting3-39–applicationContext.xml-CustomEditorConfigurerconfiguration

Project–ch03-simple-types-examples

Sourcelocation-src/main/resources/META-INF/spring

<beanid="myPropertyEditorRegistrar"

class="sample.spring.chapter03.beans.MyPropertyEditorRegistrar"/>



<beanid="editorConfigurer"

class="org.springframework.beans.factory.config.CustomEditorConfigurer">

<propertyname="propertyEditorRegistrars">

<list>

<refbean="myPropertyEditorRegistrar"/>

</list>

</property>

</bean>

In the above example listing, myPropertyEditorRegistrar bean definition configures

MyPropertyEditorRegistrarclassasaSpringbean.MyPropertyEditorRegistrarclassimplementsSpring’s

PropertyEditorRegistrar interface, and is responsible for registering additional property editors with

Spring container. CustomEditorConfigurer’s propertyEditorRegistrars property specifies a list of

PropertyEditorRegistrar implementations. In the above example listing, myPropertyEditorRegistrar is

specified as one of the values of propertyEditorRegistrars property. CustomEditorConfigurer bean is

automaticallydetectedandexecutedbytheSpringcontainer,resultinginregistrationofpropertyeditors

bytheMyPropertyEditorRegistrarinstance.

Let’s now look at how to use p-namespace (for bean properties) and c-namespace (for constructor

arguments)towriteconcisebeandefinitionsinapplicationcontextXMLfiles.

3-7Concisebeandefinitionswithpandcnamespaces

To make bean definitions less verbose in application context XML files, Spring provides p and c

namespaces tospecify values for bean properties andconstructor arguments, respectively. Thep and c

namespacesarealternativestousing<property>and<constructor-arg>elements,respectively.

Let’sfirstlookatp-namespace.

IMPORTchapter3/ch03-namespaces-example(ThisprojectshowsaSpringapplicationinwhichbean

properties and constructor arguments are set using p- and c-namespaces, respectively. To run the

application,executethemainmethodoftheSampleAppclassofthisproject)

p-namespace

Tousep-namespacetosetbeanproperties,specifybeanpropertiesasattributesofthe<bean>element,

andspecifyeachbeanpropertytobeinthep-namespace.

Thefollowingbeandefinitionshowshowtousep-namespacetosetbeanproperties:

Examplelisting3-40–applicationContext.xml-p-namespaceexample

Project–ch03-namespaces-example

Sourcelocation-src/main/resources/META-INF/spring

<beansxmlns="http://www.springframework.org/schema/beans"

xmlns:p="http://www.springframework.org/schema/p"xsi:schemaLocation=".....">



<beanid="bankDetails"class="sample.spring.chapter03.beans.BankDetails"

p:bankName="MyPersonalBank"p:bankPrimaryBusiness="Retailbanking"

p:headOfficeAddress="Addressofheadoffice"p:privateBank="Y"

p:primaryCurrency="INR"p:dateOfInception="30-01-2012"

p:branchAddresses-ref="branchAddresses"/>

.....

</beans>

In the application context XML file shown above, p-namespace is specified via xmlns attribute. The

bankDetailsbeandefinitionmakesuseofthepprefixforthep-namespacetospecifybeanproperties.If

you compare the above example listing with the example listing 3-25, you’ll notice that the above

examplelistingislessverbose.Eventhoughitispossibletouseamixof<property>elementsand p-

namespace to specify bean properties, it’s recommended that you choose one style for specifying bean

propertiesanduseitconsistentlyinbeandefinitions.

NOTE As p-namespace is implemented as part of Spring, there is no schema corresponding to p-

namespace. For this reason, you don’t see any schema reference corresponding to p-namespace in

example listing 3-40. If you want your IDE to autocomplete bean property names when using p-

namespace,considerusingIntelliJIDEAorSpringSourceToolSuite(STS).

Ifabeanpropertyisnotareferencetoanotherbean,itisspecifiedusingthefollowingsyntax:

p:<property-name>="<property-value>"



here,<property-name>isthenameofthebeanproperty,and<property-value>isthevalueofthebean

property.

Ifabeanpropertyisareferencetoanotherbean,itisspecifiedusingthefollowingsyntax:

p:<property-name>-ref="<bean-reference>"



here,<property-name>isthenameofthebeanproperty,and<bean-reference>istheid(orname)of

thereferencedbean.Itisimportanttonotethatthenameofthebeanpropertyisfollowedby--ref.Asthe

branchAddressespropertyofBankDetailsbeanrepresentsareferencetothebranchAddressesbean,the

branchAddressespropertyisspecifiedasp:branchAddresses-refinexamplelisting3-40.

Let’snowlookathowc-namespaceisusedforsettingconstructorarguments.

c-namespace

To use c-namespace to supply values for constructor arguments, specify constructor arguments as

attributesofthe<bean>element,andspecifyeachconstructorargumenttobeinthec-namespace.

ThefollowingexamplelistingshowstheBankStatementclassthatwe’llconfigureasaSpringbeanusing

c-namespace.

Examplelisting3-41–BankStatementclass

Project–ch03-namespaces-example

Sourcelocation-src/main/java/sample/spring/chapter03/beans



packagesample.spring.chapter03.beans;



importjava.beans.ConstructorProperties;



publicclassBankStatement{

.....

@ConstructorProperties({"transactionDate","amount","transactionType",

"referenceNumber"})

publicBankStatement(DatetransactionDate,doubleamount,

StringtransactionType,StringreferenceNumber){

this.transactionDate=transactionDate;

this.amount=amount;

.....

}

.....

}

ThefollowingbeandefinitionfortheBankStatementclassshowsusageofc-namespaceforsettingvalues

ofconstructorarguments:

Examplelisting3-42–applicationContext.xml-c-namespaceexample

Project–ch03-namespaces-example

Sourcelocation-src/main/resources/META-INF/spring

<beansxmlns="http://www.springframework.org/schema/beans"

xmlns:c="http://www.springframework.org/schema/c"

xsi:schemaLocation=".....">

.....

<beanid="bankStatement"class="sample.spring.chapter03.beans.BankStatement"

c:transactionDate="30-01-2012"

c:amount="1000"

c:transactionType="Credit"

c:referenceNumber="1110202"/>

.....

</beans>

In the above example listing, c-namespace is specified via xmlns attribute. The bankStatement bean

definition makes use of the c prefix for the c-namespace to specify constructor arguments. The syntax

followedforspecifyingconstructorargumentsusingc-namespaceissimilartowhatwesawincaseofp-

namespace.

NOTE As c-namespace is implemented as part of Spring, there is no schema corresponding to c-

namespace. For this reason, you don’t see any schema reference corresponding to c-namespace in

examplelisting 3-42.If youwantyour IDEtoautocompleteconstructorargumentnames whenusingc-

namespace,considerusingIntelliJIDEAorSpringSourceToolSuite(STS).

Ifaconstructorargumentisnotareferencetoanotherbean,itisspecifiedusingthefollowingsyntax:

c:<constructor-argument-name>="<constructor-argument-value>"



here, <constructor-argument-name> is the name of the constructor argument, and <constructor-

argument-value>isthevalueoftheconstructorargument.

Ifaconstructorargumentisareferencetoanotherbean,itisspecifiedusingthefollowingsyntax:

c:<constructor-argument-name>-ref="<bean-reference>"



here,<constructor-argument-name>isthenameoftheconstructorargument,and<bean-reference>is

theid(orname)ofthereferencedbean.Itisimportanttonotethatthenameoftheconstructorargumentis

followedby--ref.Forinstance,ifaconstructorargumentnamedmyargumentrepresentsareferencetoa

beanwithid‘x’,youspecifymyargumentconstructorargumentas:

c:myargument-ref="x"

As mentioned earlier, if a class is compiled with debug flag enabled, constructor argument names are

preserved in the generated .class file. If the BankStatement class is not compiled with the debug flag

enabled,theconfigurationshowninexamplelisting3-42willnotwork.Insuchcases,yousupplyvalues

forconstructorargumentsusingtheirindex,asshownhere:

Examplelisting3-43–Supplyingvaluesforconstructorargumentsusingtheirindex



<beansxmlns="http://www.springframework.org/schema/beans"

xmlns:c="http://www.springframework.org/schema/c"

xsi:schemaLocation=".....">

.....

<beanid="bankStatement"class="sample.spring.chapter03.beans.BankStatement"

c:_0="30-01-2012"

c:_1="1000"

c:_2="Credit"

c:_3="1110202"/>

.....

</beans>

The above example listing shows bean definition for the BankStatement class, which uses constructor

argument index instead of constructor arguments name to supply values. It is important to note that the

indexoftheconstructorargumentisprefixedwithanunderscorebecauseattributenamesinXMLcannot

beginwithanumericvalue.Ifaconstructorargumentisareferencetoanotherbean,-refmustbeaddedto

the index of the constructor argument. For instance, if the constructor argument at index 0 represents

referencetoanotherbean,itisspecifiedasc:_0-ref.Eventhoughit’spossibletouseacombinationof

<constructor-arg>elementsandc-namespacetospecifyconstructorarguments,it’srecommendedthatyou

chooseonestyleofspecifyingconstructorargumentsanduseitconsistentlyinbeandefinitions.

Wesawearlierhow<list>,<map>and<set>elementsareusedtosetpropertiesorconstructorarguments

oftypeList,Map andSet, respectively. Let’s now look at Spring’s util schema that simplifies creating

collectiontypes,Propertiestype,constants,andsoon,andexposingthemasaSpringbeans.

3-8Spring’sutilschema

Spring’s util schema simplifies configuring beans by providing a concise way to perform common

configurationtasks.Thefollowingtabledescribesthevariouselementsofutilschema:

Element Description

<list> Createsajava.util.Listtype,andexposesitasabean

<map> Createsajava.util.Maptype,andexposesitasabean

<set> Createsajava.util.Settype,andexposesitasabean

<constant> Exposesapublicstaticfieldonatypeasabean

<property-path> Exposesabeanpropertyasabean

<properties> Createsajava.util.Propertiesfromapropertiesfile,andexposesitasabean



NOTE All the elements of Spring’s util schema accept a scope attribute that identifies whether the

exposedbeanisasingleton-orprototype-scoped.

SpringprovidesaFactoryBeaninterfacethatcanbeimplementedtocreateafactoryobjectresponsible

forcreatingbeaninstances.Insteadofusingutilschema’selementsmentionedintheabovetable,youcan

useanout-of-the-boxFactoryBeanimplementationprovidedbySpringtoperformthesamefunctionality.

Inthissection,we’lllookattheutilschema’selementsandthebuilt-inFactoryBeanimplementationsthat

youcanuseinsteadofutilschema’selements.

IMPORTchapter3/ch03-util-schema-examples(This project shows a Spring application that makes

useofSpring’sutilschemaelementstocreatesharedinstancesofList,Set,Map,andsoon.Torunthe

application,executethemainmethodoftheSampleAppclassofthisproject)

Let’sfirstlookatthe<list>element.

<list>

The<list> element ofSpring’s util schema is used for creating objects of type java.util.List, as shown

here:

Examplelisting3-44–applicationContext.xml-utilschema’s<list>element

Project–ch03-util-schema-examples

Sourcelocation-src/main/resources/META-INF/spring

<beansxmlns="http://www.springframework.org/schema/beans"

xmlns:util="http://www.springframework.org/schema/util"

xsi:schemaLocation=".....http://www.springframework.org/schema/util

http://www.springframework.org/schema/util/spring-util-4.0.xsd">



<beanid="dataTypes"class="sample.spring.chapter03.beans.DataTypesExample">

.....

<constructor-argname="listType"ref="listType"/>

.....

</bean>



<util:listid="listType"list-class="java.util.ArrayList">

<value>AsimpleStringvalueinlist</value>

<value>AnothersimpleStringvalueinlist</value>

</util:list>

</beans>

First,youneedtoincludeSpring’sutilschematoaccessitselements.Intheaboveexamplelisting,the

<list>elementofutilschemacreatesaninstanceofjava.util.ArrayListandexposesitasabean.Theid

attribute specifies the bean id with which the java.util.ArrayList instance is exposed, and list-class

attribute specifies the concrete implementation of java.util.List that you want to create. If you don’t

specify the list-class attribute, an instance of java.util.ArrayList is created by default. The <value>

elementofSpring’sbeansschemaisusedtospecifyindividualelementsofthelist.

As util schema’s <list> element exposes a List instance as a bean, you can refer to the exposed List

instancefromotherbeans.Forinstance,intheaboveexamplelisting,thelistTypeconstructorargument

(oftypejava.util.List) of DataTypesExamplebeanspecifies listType as the value of the ref attribute to

refertotheListinstancecreatedbytheutilschema’s<list>element.

If you compare the util schema’s <list> element shown in the above example listing with the beans

schema’s<list>element(referexamplelisting3-27),you’llnoticethattheutilschema’s<list>element

gives youcontrol over the List implementation to create.  For instance, if you want to create a Vector

insteadofanArrayListinstance,specifyjava.util.Vectorasthevalueofthelist-classattribute.

Let’snowlookatSpring’sListFactoryBeanwhichyoucanuseinsteadofutilschema’s<list>element.

ListFactoryBean

Analternativetousingutilschema’s<list>elementisSpring’sListFactoryBean–afactorythatisused

forcreatinginstancesofjava.util.ListandmakingthemavailableasSpringbeans.

ThefollowingexamplelistingshowshowtheListFactoryBeancanbeusedinsteadoftheutilschema’s

<list>element:

Examplelisting3-45–ListFactoryBeanexample



<beans.....>



<beanid="dataTypes"class="sample.spring.chapter03.beans.DataTypesExample">

.....

<constructor-argname="listType"ref="listType"/>

.....

</bean>



<beanid="listType"class="org.springframework.beans.factory.config.ListFactoryBean">

<propertyname="sourceList">

<list>

<value>AsimpleStringvalueinlist</value>

<value>AnothersimpleStringvalueinlist</value>

</list>

</property>

</bean>

</beans>

Intheaboveexamplelisting,thesourceListpropertyofListFactoryBeanspecifiestheelementsinthelist.

Bydefault,ListFactoryBeancreatesaninstanceofjava.util.ArrayList.IfyouwanttheListFactoryBeanto

createaninstanceofanyotherListimplementation(likeVector),settheListFactoryBean’stargetListClass

property.ThetargetListClasspropertyspecifiesthefully-qualifiednameoftheconcreteimplementation

classofjava.util.ListinterfacethatshouldbecreatedbytheListFactoryBean.

Ifyoucompareexamplelistings3-44and3-45,you’llnoticethatusingutilschema’s<list>elementisa

lotsimplerthanusingtheListFactoryBeantocreateaListinstanceandexposeitasabean.

<map>

The <map> element of Spring’s util schema is used for creating an object of type java.util.Map and

exposingitasabean,asshownhere:

Examplelisting3-46–applicationContext.xml-utilschema’s<map>element

Project–ch03-util-schema-examples

Sourcelocation-src/main/resources/META-INF/spring

<beans.....

xmlns:util="http://www.springframework.org/schema/util"

xsi:schemaLocation=".....http://www.springframework.org/schema/util

http://www.springframework.org/schema/util/spring-util-4.0.xsd">



<beanid="dataTypes"class="sample.spring.chapter03.beans.DataTypesExample">

.....

<constructor-argname="mapType"ref="mapType"/>

.....

</bean>



<util:mapid="mapType"map-class="java.util.TreeMap">

<entrykey="mapkey1"value="mapkey1’svalue"/>

</util:map>

.....

</beans>

Intheaboveexamplelisting,utilschema’s<map>elementcreatesaninstanceofjava.util.TreeMapand

exposes it as a bean. The id attribute specifies the id with which the bean is made available to other

beans,andmap-classattributespecifiesthefully-qualifiednameoftheconcreteimplementationclassof

java.util.Map interface that should be created by the <map> element. The <entry> element of Spring’s

beansschemaspecifiesakey-valuepairinthecreatedMapinstance.

Asthe<map>elementexposesaMapinstanceasabean,theexposedMapinstancecanbereferenced

fromotherbeans.Forinstance,intheaboveexamplelisting,DataTypesExample’smapTypeconstructor

argument (of type java.util.Map) specifies value of ref attribute as mapType to refer to the TreeMap

instancecreatedbythe<map>element.

NOTEWesawearlierinthischapterthat<key>and<value>sub-elementsof<entry>areusedtospecify

akey-valuepaircontainedintheMapinstance.Theexamplelisting3-46showsthatyoucanalsospecify

akey-valuepaircontainedintheMapinstancebyusing<entry>element’skeyandvalueattributes.

If you compare the util schema’s <map> element shown in the above example listing with the beans

schema’s <map> element in example listing 3-27, you’ll notice that the util schema’s <map> element

gives you control over the Map implementation to create.  For instance, if you want to use

LinkedHashMap instead of TreeMap, specify java.util.LinkedHashMap as the value of map-class

attribute. If you don’t specify the map-class attribute, Spring container creates an instance of

java.util.LinkedHashMapbydefault.

Let’snowlookatSpring’sMapFactoryBeanthatyoucanuseinsteadofutilschema’s<map>element.

MapFactoryBean

Insteadofusingutilschema’s<map>element,youcanuseSpring’sMapFactoryBean–afactorythatis

usedforcreatinginstancesofjava.util.MapandmakingthemavailableasSpringbeans.

ThefollowingexamplelistingshowshowMapFactoryBeanisused:

Examplelisting3-47–MapFactoryBeanexample



<beans.....>



<beanid="dataTypes"class="sample.spring.chapter03.beans.DataTypesExample">

.....

<constructor-argname="mapType"ref="mapType"/>

.....

</bean>



<beanid="mapType"class="org.springframework.beans.factory.config.MapFactoryBean">

<propertyname="sourceMap">

<map>

<entrykey="mapkey1"value="mapkey1’svalue"/>

</map>

</property>

</bean>

.....

</beans>

In the above example listing, MapFactoryBean’s sourceMap property specifies the key-value pairs

containedintheMapinstancecreatedbytheMapFactoryBean.Bydefault,MapFactoryBeancreatesan

instanceofjava.util.LinkedHashMap.YoucancontroltheMapinstancecreatedbyMapFactoryBeanby

setting the targetMapClass property. The targetMapClass specifies the fully-qualified name of the

concreteimplementationclassofjava.util.Mapinterface.Forinstance,ifyouspecifyjava.util.HashMap

asthevalueoftargetMapClass,MapFactoryBeancreatesaninstanceofjava.util.HashMap.

If you compare example listings 3-46 and 3-47, you’ll notice that using util schema’s <map> element

resultsinamoreconciseconfigurationthanMapFactoryBeanforcreatingMapinstances.

<set>

The<set>elementofSpring’sutilschemaisusedforcreatinganobjectoftypejava.util.Setandexposing

itasabean,asshownhere:

Examplelisting3-48–applicationContext.xml-utilschema’s<set>element

Project–ch03-util-schema-examples

Sourcelocation-src/main/resources/META-INF/spring

<beans.....

xmlns:util="http://www.springframework.org/schema/util"

xsi:schemaLocation=".....http://www.springframework.org/schema/util

http://www.springframework.org/schema/util/spring-util-4.0.xsd">



<beanid="dataTypes"class="sample.spring.chapter03.beans.DataTypesExample">

.....

<constructor-argname="setType"ref="setType"/>

</bean>

<util:setid="setType"set-class="java.util.HashSet">

<value>Element1</value>

<value>Element2</value>

</util:set>

.....

</beans>

Intheaboveexamplelisting,utilschema’s<set>elementcreatesaninstanceofHashSetandexposesitas

aSpringbeanwithidassetType.Theidattributespecifiestheidwithwhichthebeanismadeavailable

to other beans, and the set-class attribute specifies the concrete implementation class of java.util.Set

interface that should be created by the <set> element. The <value> element of Spring’s beans schema

specifiesanelementinthecreatedSetinstance.

TheSetinstancecreatedbythe<set>elementcanbereferencedfromotherbeans.Forinstance,inthe

aboveexamplelisting,DataTypesExample’ssetTypeconstructorargument(oftypejava.util.Set)refersto

theHashSetinstancecreatedbythe<set>element.

Insteadofusingutilschema’s<set>element,youcanuseSpring’sSetFactoryBeantocreateaSetinstance

andexposeitasaSpringbean.

SetFactoryBean

Spring’sSetFactoryBeanisafactoryobjectforcreatinginstancesofjava.util.Settype.

ThefollowingexamplelistingshowshowyoucanuseSetFactoryBeantoperformthesamefunctionasthe

utilschema’s<set>element:

Examplelisting3-49–SetFactoryBeanexample



<beans.....>



<beanid="dataTypes"class="sample.spring.chapter03.beans.DataTypesExample">

.....

<constructor-argname="setType"ref="setType"/>

.....

</bean>



<beanid="setType"class="org.springframework.beans.factory.config.SetFactoryBean">

<propertyname="sourceSet">

<set>

<value>Element1</value>

<value>Element2</value>

</set>

</property>

</bean>

.....

</beans>

Intheaboveexamplelisting,SetFactoryBean’ssourceSetpropertyspecifiestheelementscontainedinthe

SetinstancecreatedbytheSetFactoryBean.SetFactoryBean’stargetSetClasspropertyspecifiesthefully-

qualified name of the class that implements java.util.Set interface. If the targetSetClass property is

specified,SetFactoryBeancreatesaninstance of the class specified bythe targetSetClass property and

makes it available as a Spring bean. For instance, if you specify java.util.HashSet as the value of

targetSetClass,SetFactoryBeancreatesaninstanceofjava.util.HashSet.IfthetargetSetClasspropertyis

unspecified,SetFactoryBeancreatesaninstanceofjava.util.LinkedHashSet.

The above example listing shows that using util schema’s <set> element results in a more concise

configurationthanusingSetFactoryBeanforcreatingSetinstances.

Theutilschema’s<properties>elementisusefulifyouwanttocreateaninstanceofjava.util.Properties

objectfromapropertiesfile,andexposethejava.util.Propertiesobjectasabean.

Thefollowingexamplelistingshowshowthe<properties>elementisused:

Examplelisting3-50–applicationContext.xml-utilschema’s<properties>element

Project–ch03-util-schema-examples

Sourcelocation-src/main/resources/META-INF/spring

<beans.....

xmlns:util="http://www.springframework.org/schema/util"

xsi:schemaLocation=".....http://www.springframework.org/schema/util

http://www.springframework.org/schema/util/spring-util-4.0.xsd">



<beanid="bankDetails"class="sample.spring.chapter03.beans.BankDetails">

.....

<propertyname="branchAddresses"ref="branchAddresses"/>

</bean>

.....

<util:propertiesid="branchAddresses"

location="classpath:META-INF/addresses.properties"/>

</beans>

Intheaboveexamplelisting,<properties>elementcreatesaninstanceofjava.util.Propertiescontaining

propertiesloadedfromtheaddresses.propertiesfile(specifiedbythelocationattribute),andexposesthe

java.util.PropertiesinstanceasabeanwithbranchAddressesastheid(specifiedbytheidattribute).The

above example listing also shows that the branchAddresses property (of type java.util.Properties) of

BankDetailsbeanreferstothebranchAddressesbeancreatedbytheutilschema’s<properties>element.

Analternativetousingthe<properties>elementisSpring’sPropertiesFactoryBean.

PropertiesFactoryBean

Spring’sPropertiesFactoryBeanisafactoryforcreatinginstancesofjava.util.Properties.

The following example listing shows how you can use PropertiesFactoryBean to perform the same

functionastheutilschema’s<properties>element:

Examplelisting3-51–PropertiesFactoryBeanexample



<beans.....>



<beanid="bankDetails"class="sample.spring.chapter03.beans.BankDetails">

.....

<propertyname="branchAddresses"ref="branchAddresses"/>

</bean>



<beanid="branchAddresses"

class="org.springframework.beans.factory.config.PropertiesFactoryBean">

<propertyname="location"value="classpath:META-INF/addresses.properties"/>

</bean>

.....

</beans>

Intheaboveexamplelisting,beandefinitionforSpring’sPropertiesFactoryBeancreates an instance of

java.util.Properties from the properties loaded from addresses.properties file (specified by location

property),andexposesthejava.util.PropertiesinstanceasabeanwithbranchAddressesastheid.

Theutilschema’s<constant>elementisusedforexposinganobject’spublicstaticfieldasaSpringbean.

Thefollowingexamplelistingshowsanexampleusageof<constant>element:

Examplelisting3-52–applicationContext.xml-utilschema’s<constant>element

Project–ch03-util-schema-examples

Sourcelocation-src/main/resources/META-INF/spring

<beans.....xmlns:util="http://www.springframework.org/schema/util"

xsi:schemaLocation=".....http://www.springframework.org/schema/util

http://www.springframework.org/schema/util/spring-util-4.0.xsd">



<beanid="dataTypes"class="sample.spring.chapter03.beans.DataTypesExample">

.....

<constructor-argname="booleanType"ref="booleanTrue"/>

.....

</bean>



<util:constantid="booleanTrue"static-field="java.lang.Boolean.TRUE"/>

.....

</beans>

Theutilschema’s<constant>elementexposesthevaluespecifiedbyitsstatic-fieldattributeasaSpring

bean. In the above example listing, <constant> element exposes a bean whose value is

java.lang.Boolean.TRUEandidisbooleanTrue.Youcanspecifyanypublicstaticfieldasthevalueofthe

static-fieldattributeand refertoitfromotherbeansintheSpringcontainer.Forinstance,intheabove

example listing, booleanType bean is referenced by DataTypesExample’s booleanType constructor

argumentoftypeboolean.

A rather less concise way to expose public static fields as Spring beans is to use Spring’s

FieldRetrievingFactoryBean.

FieldRetrievingFactoryBean

Spring’sFieldRetrievingFactoryBeanisafactoryforretrievingvalueofapublicstaticfieldspecifiedby

the FieldRetrievingFactoryBean’s staticField property. The value retrieved by the

FieldRetrievingFactoryBeanisexposedasabean.YoucanalsousetheFieldRetrievingFactoryBeanto

retrieveanon-staticfieldvalue.

ThefollowingexamplelistingshowsanexampleusageofFieldRetrievingFactoryBean:

Examplelisting3-53–FieldRetrievingFactoryBeanexample



<beans.....>



<beanid="dataTypes"class="sample.spring.chapter03.beans.DataTypesExample">

.....

<constructor-argname="booleanType"ref="booleanTrue"/>

.....

</bean>



<beanid="booleanTrue"

class="org.springframework.beans.factory.config.FieldRetrievingFactoryBean">

<propertyname="staticField"value="java.lang.Boolean.TRUE"/>

</bean>

.....

</beans>

Intheaboveexamplelisting,FieldRetrievingFactoryBeanretrievesthevalueofjava.lang.Boolean.TRUE

field and exposes it as a bean. The bean exposed by the FieldRetrievingFactoryBean is referenced by

DataTypesExample’sbooleanTypeconstructorargumentoftypeboolean.

<property-path>

Theutilschema’s<property-path>elementisusedtoexposeabeanpropertyvalueasabean.

Thefollowingexamplelistingshowsanexampleusageof<property-path>element:

Examplelisting3-54–applicationContext.xml-utilschema’s<property-path>element

Project–ch03-util-schema-examples

Sourcelocation-src/main/resources/META-INF/spring

<beans.....

xmlns:util="http://www.springframework.org/schema/util"

xsi:schemaLocation=".....http://www.springframework.org/schema/util

http://www.springframework.org/schema/util/spring-util-4.0.xsd">



<beanid="bankDetails"class="sample.spring.chapter03.beans.BankDetails">

.....

<propertyname="dateOfInception"ref="dateType"/>

.....

</bean>



<util:property-pathid="dateType"path="dataTypes.dateType"/>



<beanid="dataTypes"class="sample.spring.chapter03.beans.DataTypesExample">

.....

<propertyname="dateType"value="30-01-2012"/>

.....

</bean>

</beans>

In the above example listing, DataTypesExample’s dateType property (of type java.util.Date) value is

specified as ‘30-01-2012’. The <property-path> element retrieves the DataTypesExample’s dateType

propertyandexposesitasabeanwithidasdateType.Thepathattributeof<property-path>elementhas

thefollowingsyntax:

<bean-name>.<bean-property>

Here,<bean-name>istheidornameofthebean,and<bean-property>isthenameoftheproperty.

As<property-path>elementexposesa bean,theexposedbean canbereferencedbyother beansinthe

Spring container. For instance in the above example listing, dateType bean is referenced by

dateOfInceptionpropertyofBankDetailsbean.

Instead of using <property-path> element, you can use Spring’s PropertyPathFactoryBean to expose a

beanpropertyvalueasabean.

PropertyPathFactoryBean

PropertyPathFactoryBean is a factory used for creating bean instances that represent a bean property

value.

ThefollowingexamplelistingshowshowtousePropertyPathFactoryBean:

Examplelisting3-55–PropertyPathFactoryBeanexample



<beans.....

xmlns:util="http://www.springframework.org/schema/util"

xsi:schemaLocation=".....http://www.springframework.org/schema/util

http://www.springframework.org/schema/util/spring-util-4.0.xsd">



<beanid="bankDetails"class="sample.spring.chapter03.beans.BankDetails">

.....

<propertyname="dateOfInception"ref="dateType"/>

.....

</bean>



<beanid="dataType"

class="org.springframework.beans.factory.config.PropertyPathFactoryBean">

<propertyname="targetBeanName"value="dataTypes"/>

<propertyname="propertyPath"value="dateType"/>

</bean>



<beanid="dataTypes"class="sample.spring.chapter03.beans.DataTypesExample">

.....

<propertyname="dateType"value="30-01-2012"/>

.....

</bean>

</beans>

In the above example listing, PropertyPathFactoryBean is used to create an instance of a bean that

representsthevalueofdateTypepropertyofdataTypesbean.PropertyPathFactoryBean’stargetBeanName

attributespecifiestheidornameofthebeanthatcontainstheproperty,andPropertyPathFactoryBean’s

propertyPath attribute specifies thename ofthe property whose valueis tobeexposed as a bean. The

bean instance created by PropertyPathFactoryBean can be accessed by other beans in the Spring

container. In the above example listing, the dataType bean created by PropertyPathFactoryBean is

referencedbydateOfInceptionproperty(oftypejava.util.Date)ofBankDetailsbean.

Now, that we have taken an in-depth look at util schema elements, let’s look at Spring’s FactoryBean

interface.

3-9FactoryBeaninterface

Spring’sFactoryBeaninterfaceisimplementedbyclassesthatactasafactoryforcreatingbeaninstances.

Intheprevioussection,wesawthattheclassesthatimplementtheFactoryBeaninterfaceareconfigured

intheapplicationcontextXMLfilelikeanyotherbean.FactoryBeanisparticularlyusefulifyouwantto

performcomplicatedconditionalcheckstodecideonwhichbeantypetocreate,andtoexecutecomplex

beaninitializationlogic.

Let’snowlookatanapplicationscenarioinwhichwe’lluseFactoryBeanforselectingabeantype,and

thencreatingit.

MyBankapplication–Storingeventsinthedatabase

In MyBank application, important events, like credit and debit transactions, open and liquidate fixed

deposits,andsoon,aresavedinthedatabase.MyBankmaydirectlysavetheseeventsinthedatabaseor

indirectlybyfirstsendingtheeventstoamessagingmiddlewareorawebservice.Thefollowingtable

describestheclassesthataredefinedbytheMyBankapplicationfordirectlyorindirectlysavingevents:

Class Description

DatabaseEventSender

Classthatcontainsthefunctionalityforsavingeventsinthedatabase

MessagingEventSender Classthatcontainsthefunctionalityforsendingeventstoamessagingmiddleware

WebServiceEventSender Classthatcontainsthefunctionalityforsendingeventstoaremotewebservice



Thedecisiontodirectlysavetheeventsinthedatabaseortosendthemtoamessagingmiddlewareora

web service is based on configuration. For instance, if MyBank finds that there exists a

database.properties file, MyBank reads the configuration information (like database url, username and

password)fromthedatabase.propertiesfileandcreatestheDatabaseEventSenderinstance.Similarly,ifa

messging.propertiesfileexists,MyBankcreatesaninstanceofMessagingEventSenderinstance,andifa

webservice.propertiesfileexists,aninstanceofWebServiceEventSenderiscreated.

Initializing DatabaseEventSender, MessagingEventSender and WebServiceEventSender instances may

require executing complex initialization logic. For instance, you need to create (or obtain from JNDI)

javax.jms.ConnectionFactory and javax.jms.Destination instances and set them on the

MessagingEventSender instance so that the MessagingEventSender can send JMS messages to the

messagingmiddleware.

The following class diagram shows that the FixedDepositServiceImpl class of MyBank uses either

DatabaseEventSender or MessagingEventSender or WebServiceEventSender instance to directly or

indirectlysaveeventsrelatedtofixeddepositsinthedatabase:

Figure3-7FixedDepositServiceImplclassusesoneoftheimplementationsofEventSenderinterface.

Intheaboveclassdiagram,sendEventmethodofEventSenderinterfacedefinesthecontractfordirectly

or indirectly saving events in the database. DatabaseEventSender, MessagingEventSender and

WebServiceEventSender classes implement the EventSender interface and provide an appropriate

implementationforthesendEventmethod.

Let’snowlookathowFactoryBeansimplifieschoosingtherightimplementationofEventSenderinterface

andinitializingit.

IMPORTchapter3/ch03-bankapp-factorybean(ThisprojectshowstheMyBankapplicationthatusesa

FactoryBean implementation to create objects of type EventSender. To run the application, execute the

mainmethodoftheBankAppclassofthisproject)

MyBank–FactoryBeanexample

In MyBank, selecting the right EventSender implementation and initializing it is an involved task;

therefore,itrepresentsanidealscenarioforusingaFactoryBeanimplementation.FactoryBeaninterface

definesthefollowingmethodsthatyouneedtoimplement:

·getObjectType:returnsthetypeoftheobjectmanagedbytheFactoryBeanimplementation.In

caseofMyBank,theFactoryBeanimplementationcreatesandreturnsobjectsoftypeEventSender.

·getObject:returnstheobjectmanagedbytheFactoryBeanimplementation.IncaseofMyBank,

the getObject method returns an instance of DatabaseEventSender or MessagingEventSender or

WebServiceEventSender.

·  isSingleton:returnstrueiftheFactoryBean implementation is afactoryfor singleton-scoped

objects.IftheisSingletonmethodreturnstrue,theobjectreturnedbythegetObjectmethodiscached

bytheSpringcontainerandthesameinstanceisreturnedonsubsequentrequests.IftheFactoryBean

implementationisafactoryforprototype-scopedobjects,returnfalsefromtheisSingletonmethod.

IftheisSingletonmethod returns false, a fresh instance is created by getObject method on every

request. In case of MyBank, FactoryBean implementation returns an instance of

DatabaseEventSender or MessagingEventSender or WebServiceEventSender class. Once created,

the same instance is used throughout the lifetime of the MyBank application; therefore, the

isSingletonmethodreturnstrueincaseofMyBank.

ThefollowingexamplelistingshowstheEventSenderFactoryBean–theFactoryBeanimplementationthat

createsandreturnsobjectsoftypeEventSender:

Examplelisting3-56–EventSenderFactoryBeanclass

Project–ch03-bankapp-factorybean

Sourcelocation-src/main/java/sample/spring/chapter03/bankapp/event



packagesample.spring.chapter03.bankapp.event;



importorg.springframework.beans.factory.FactoryBean;

importorg.springframework.beans.factory.FactoryBeanNotInitializedException;

importorg.springframework.core.io.ClassPathResource;

.....

publicclassEventSenderFactoryBeanimplementsFactoryBean<EventSender>{

privateStringdatabasePropertiesFile;

privateStringwebServicePropertiesFile;

privateStringmessagingPropertiesFile;

.....

publicEventSendergetObject()throwsException{

EventSendereventSender=null;

Propertiesproperties=newProperties();



ClassPathResourcedatabaseProperties=null;

if(databasePropertiesFile!=null){

databaseProperties=newClassPathResource(databasePropertiesFile);

}

.....

if(databaseProperties!=null&&databaseProperties.exists()){

InputStreaminStream=databaseProperties.getInputStream();

properties.load(inStream);

eventSender=newDatabaseEventSender(properties);

}

elseif(webServiceProperties!=null&&webServiceProperties.exists()){.....}

elseif(messagingProperties!=null&&messagingProperties.exists()){.....}



returneventSender;

}



publicClass<?>getObjectType(){

returnEventSender.class;

}



publicbooleanisSingleton(){

returntrue;

}

}

The above example listing shows that the EventSenderFactoryBean implements FactoryBean interface.

The EventSender parameter in FactoryBean<EventSender> indicates that the FactoryBean’s getObject

returns objects of type EventSender. The databasePropertiesFile, webServicePropertiesFile and

messagingPropertiesFile are properties of the EventSenderFactoryBean class, and they represent the

locationofdatabase.properties,webservice.propertiesandmessaging.propertiesfilesintheclasspath.

ThegetObjectmethodusesSpring’sClassPathResourceclasstoverifywhetherthespecifiedproperties

file exists in the classpath or not. If the properties file exists, properties from that file are loaded and

passed as to the EventSender implementation class’s constructor. For instance, in the above example

listing,ifdatabase.propertiesfile(representedbydatabasePropertiesFileproperty)exists,propertiesare

loaded from the database.properties file and passed as an argument to the DatabaseEventSender’s

constructor.ThegetObjectTypemethodreturnsEventSendertypebecausetheEventSenderFactoryBean’s

getObjectmethodreturnsobjectsoftypeEventSender.TheisSingletonmethodreturnstrue,whichmeans

thattheobjectreturnedbygetObjectmethodiscachedbySpringandthesameinstanceisreturnedevery

timeEventSenderFactoryBean’sgetObjectmethodisinvoked.

Now, that you have seen how EventSenderFactoryBean class is implemented in the MyBank, you can

guesshowSpring’sbuilt-inFactoryBeanimplementations,likeListFactoryBean(forcreatinginstancesof

Listtype),MapFactoryBean(forcreatinginstancesofMaptype),SetFactoryBean(forcreatinginstances

ofSettype),andsoon,areimplemented.

The following example listing shows how EventSenderFactoryBean is configured in the application

contextXMLfile:

Examplelisting3-57–applicationContext.xml-EventSenderFactoryBeanconfiguration

Project–ch03-bankapp-factorybean

Sourcelocation-src/main/resources/META-INF/spring

<beans.....>



<beanid="service"

class="sample.spring.chapter03.bankapp.service.FixedDepositServiceImpl">

.....

<propertyname="eventSender"ref="eventSenderFactory"/>

</bean>

.....

<beanid="eventSenderFactory"

class="sample.spring.chapter03.bankapp.event.EventSenderFactoryBean">

<propertyname="databasePropertiesFile"value="META-INF/config/database.properties"/>

</bean>

</beans>

The above example listing shows thattheEventSenderFactoryBean is configured likeanyother Spring

bean.EventhoughaFactoryBeanimplementationisconfiguredlikeanyotherSpringbean,itistreated

differentlybytheSpringcontainer.Oneofthemostimportantdifferencesisthatifabeanisdependenton

a FactoryBean implementation, the Spring container invokes the getObject method of the FactoryBean

implementationandinjectsthereturnedobjectintothedependentbean.

NOTEYoushouldnotethatFactoryBean’sgetObjectmethodisinvokedonlyoncebytheSpring

containeriftheisSingletonmethodreturnstrue.

In the above example listing, bean definition for the FixedDepositServiceImpl class shows that it is

dependent on the EventSenderFactoryBean – a FactoryBean implementation. So, the Spring container

invokestheEventSenderFactoryBean’sgetObjectmethodandinjectsthereturnedEventSenderobjectinto

theFixedDepositServiceImplinstance.

The following example listing shows the FixedDepositServiceImpl class that requires EventSender

instancecreatedbyEventSenderFactoryBean:

Examplelisting3-58–FixedDepositServiceImplclass

Project–ch03-bankapp-factorybean

Sourcelocation-src/main/java/sample/spring/chapter03/bankapp/service



packagesample.spring.chapter03.bankapp.service;



importsample.spring.chapter03.bankapp.event.EventSender;



publicclassFixedDepositServiceImplimplementsFixedDepositService{

.....

privateEventSendereventSender;



publicvoidsetEventSender(EventSendereventSender){

this.eventSender=eventSender;

}

.....

publicvoidcreateFixedDeposit(FixedDepositDetailsfixedDepositDetails){

.....

eventSender.sendEvent(event);

}

}

The above example listing shows that the FixedDepositServiceImpl class depends on an EventSender

instanceandnotontheEventSenderFactoryBeaninstance.TheSpringcontainerobtainstheEventSender

instancebyinvokingEventSenderFactoryBean’sgetObjectmethod,andinjectstheobtainedEventSender

instanceintotheFixedDepositServiceImplinstance.

Let’snow lookathowto access theFactoryBean itself and not the bean it creates and returns via the

getObjectmethod.

AccessingtheFactoryBeaninstance

If you want to obtain the FactoryBean itself from the Spring container, prefix the name (or id) of the

factorybeanwithampersand‘&’.

Let’ssaythattheFixedDepositServiceImplclassrequiresaccesstotheEventSenderFactoryBeanitself,

asshownhere:

Example listing 3-59 – FixedDepositServiceImpl class that depends on the EventSenderFactoryBean

itself



packagesample.spring.chapter03.bankapp.service;



importsample.spring.chapter03.bankapp.event.EventSenderFactoryBean;

importsample.spring.chapter03.bankapp.event.EventSender;



publicclassFixedDepositServiceImplimplementsFixedDepositService{

.....

privateEventSenderFactoryBeaneventSenderFactoryBean;



publicvoidsetEventSenderFactoryBean(EventSenderFactoryBeaneventSenderFactoryBean){

this.eventSenderFactoryBean=eventSenderFactoryBean;

}

.....

publicvoidcreateFixedDeposit(FixedDepositDetailsfixedDepositDetails){

.....

EventSendereventSender=eventSenderFactoryBean.getObject();

evenSender.sendEvent(event);

}

}

Intheaboveexamplelisting,theFixedDepositServiceImplclassdependsontheEventSenderFactoryBean

itself,andusesitsgetObjectmethodtoobtainaninstanceofEventSenderobject.

Wesawinexamplelisting3-57thatwhenyoudefinetheEventSenderFactoryBeanbeanasadependency

of FixedDepositServiceImpl bean, the Spring container invokes the getObject method of

EventSenderFactoryBeanandinjectsthereturnedEventSenderobjectintotheFixedDepositServiceImpl

bean. To instruct the Spring container to inject the EventSenderFactoryBean itself, add ampersand ‘&’

prefixtotheid(orname)ofthebeanspecifiedbytherefattribute,asshowninthefollowingexample

listing:

Examplelisting3-60–InjectingtheEventSenderFactoryBeaninstanceintotheFixedDepositServiceImpl

bean



<beans.....>



<beanid="service"class="sample.spring.chapter03.bankapp.service.FixedDepositServiceImpl">

.....

<propertyname="eventSenderFactoryBean"ref="&eventSenderFactory"/>

</bean>

.....

<beanid="eventSenderFactory"

class="sample.spring.chapter03.bankapp.event.EventSenderFactoryBean">

<propertyname="databasePropertiesFile"value="META-INF/config/database.properties"/>

</bean>

</beans>

In the above example listing, the following <property> element specifies that the

FixedDepositServiceImplbeanisdependentonEventSenderFactoryBean:

<propertyname="eventSenderFactoryBean"ref="&eventSenderFactory"/>

Noticethattherefattribute’svalueis"&eventSenderFactory".The&prefixinstructstheSpring

containertoinjecttheEventSenderFactoryBeaninstanceitselfintotheFixedDepositServiceImplbean.

The use of ampersand ‘&’ is also required when you want to retrieve the FactoryBean instance itself

usingApplicationContext’sgetBeanmethod.ThefollowingexamplelistingshowstheBankAppclassof

MyBankapplicationthatretrievestheEventSenderobjectcreatedbytheEventSenderFactoryBean, and

theEventSenderFactoryBeaninstanceitself:

Examplelisting3-61–BankAppclass

Project–ch03-bankapp-factorybean

Sourcelocation-src/main/java/sample/spring/chapter03/bankapp

packagesample.spring.chapter03.bankapp;

.....

publicclassBankApp{

privatestaticLoggerlogger=Logger.getLogger(BankApp.class);



publicstaticvoidmain(Stringargs[]){

ApplicationContextcontext=newClassPathXmlApplicationContext(

.....

logger.info("InvokinggetBean(\"eventFactory\")returns:"+

context.getBean("eventSenderFactory"));

logger.info("InvokinggetBean(\"&eventFactory\")returns:"+

context.getBean("&eventSenderFactory"));

}

}

If you execute the main method of the BankApp class shown above, you’ll find that calling

getBean("eventSenderFactory") returns an instance of DatabaseEventSender class, and

getBean("&eventSenderFactory")returnsEventSenderFactoryBeaninstance.

3-10Summary

In this chapter, we saw how you can use bean definition inheritance to create less verbose and easily

manageablebeandefinitions.Themajorityofthischapterfocusedonhowtosetdifferenttypesofbean

properties andconstructorargumentsusingbuilt-inFactoryBeanimplementations,Spring’sutil schema,

and p- and c-namespaces. We also looked at some of the built-in PropertyEditor implementations in

SpringandhowtoregisteradditionalpropertyeditorswiththeSpringcontainer.Inthenextchapter,we’ll

takeanin-depthlookatdependencyinjectionfeatureofSpring.

Chapter4-Dependencyinjection

4-1Introduction

In the previous chapter, we looked at how to configure beans using Spring’s util schema, p- and c-

namespaces,FactoryBeanimplementations,andsoon.Inthischapterwefocusondifferentdependency

injectionscenarios which we typically come across inreal world application development efforts and

howSpringaddressesthesescenarios.

We’llbeginthischapterwithalookatinnerbeans-analternativetousingtherefattributeof<property>

and<constructor-arg> elements. We’ll then look at depends-on attribute of the <bean> element. In the

second half of this chapter, we’ll look at issues that may arise when singleton- and prototype-scoped

beans collaborate to provide application behavior. We’ll wrap this chapter with an in-depth look at

Spring’sautowiringfeature.

IMPORTchapter4/ch04-bankapp-dependencies(Thisprojectshowsusageofinnerbeansand<bean>

element’sdepends-onattribute.Thisprojectalsoshowsimplicationsofdefiningdependenceofsingleton-

scopedbeansonprototype-scopedbeans,andviceversa.Toruntheapplication,executethemainmethod

oftheBankAppclassofthisproject)

4-2Innerbeans

Ifadependencyofabeanisnotsharedbymultiplebeans,youcanconsiderdefiningthedependencyasan

inner bean. An inner bean is defined inside a <property> or <constructor-arg> element by using the

<bean>elementofSpring’sbeansschema.Youshouldnotethataninnerbeanisonlyaccessibletothe

beandefinitionenclosingit,andnottootherbeansregisteredwiththeSpringcontainer.

Thefollowingexamplelistingshowshowwegenerallyrepresentbeandependencies:

Examplelisting4-1–Dependencyspecifiedusing<property>element’srefattribute



<beanid="service"

class="sample.spring.chapter04.bankapp.service.FixedDepositServiceImpl">

<propertyname=“fixedDepositDao"ref="dao"/>

</bean>



<beanid="dao"class="sample.spring.chapter04.bankapp.dao.FixedDepositDaoImpl"/>

Theaboveexamplelistingshowsthattheservicebeanisdependentondaobean.Ifservicebeanisthe

onlybeanthatisdependentonthedaobean,thenyoucandefinethedaobeanasaninnerbeanofservice

bean.

Examplelisting4-2–applicationContext.xml-Innerbeanexample

Project–ch04-bankapp-dependencies

Sourcelocation-src/main/resources/META-INF/spring



<beanid="service"

class="sample.spring.chapter04.bankapp.service.FixedDepositServiceImpl">

<propertyname=“fixedDepositDao">

<beanclass="sample.spring.chapter04.bankapp.dao.FixedDepositDaoImpl"/>

</property>

</bean>

In the above example listing, the bean definition for the FixedDepositDaoImpl class is inside the

<property>elementofservicebean.Ifyoucomparetheaboveexamplelistingwith4-1,you’llnoticethat

the<property> element no longer specifies the ref attribute, and the <bean> element corresponding to

FixedDepositDaoImplclassdoesn’thavetheidattributeanymore.

The<bean>elementcorrespondingtoaninnerbeandefinitiondoesn’tspecifyanidattributebecausean

inner bean is not registered with the Spring container. If you specify an id attribute for an inner bean

definition,itisignoredbytheSpringcontainer.Aninnerbeanisalwaysprototype-scoped;therefore,if

the <bean> element corresponding to an inner bean definition specifies the scope attribute, then it is

ignoredbytheSpringcontainer.Itisimportanttonotethataninnerbeanisanonymousinnature,andit’s

not accessible to other beans (except the bean that contains the inner bean definition) in the Spring

container.

NOTEAsincaseofnormalbeandefinition,youcanuse<property>,<constructor-arg>,andsoon,

elementsinsidethe<bean>elementoftheinnerbeandefinition.

Inthepreviouschapter,wesawthatSpring’sutilschemaelementsareusedtocreatebeansthatrepresent

a List, Set, Map, and so on. We saw that the beans created by Spring’s util schema elements are

referenced by other beans. The concept of inner beans makes it possible to use Spring’s util schema

elements inside <property> and <constructor-arg> elements also, as shown in the following example

listing:

Examplelisting4-3–utilschema’s<list>elementdefinesaninnerbean



<beansxmlns="http://www.springframework.org/schema/beans"

xmlns:util="http://www.springframework.org/schema/util"

xsi:schemaLocation=".....http://www.springframework.org/schema/util

http://www.springframework.org/schema/util/spring-util-4.0.xsd">



<beanid="someBean"class="com.sample.SomeBean">

.....

<constructor-argname="listType">

<util:listlist-class="java.util.ArrayList">

<value>AsimpleStringvalueinlist</value>

<value>AnothersimpleStringvalueinlist</value>

</util:list>

</constructor-arg>

.....

</bean>

</beans>

Intheaboveexamplelisting,thelistTypeconstructorargumentisoftypejava.util.List.Thevaluepassed

tothelistTypeconstructorargumentisspecifiedbytheutilschema’s<list>element.Notethatwedidn’t

specifytheidattributeofthe<list>elementbecauseSpringcontainerignoresidsofinnerbeans.

Let’snowlookatdepends-onattributeof<bean>element.

4-3Explicitlycontrollingthebeaninitializationorderwithdepends-on

attribute

Insection1-4ofchapter1,wediscussedthatbeansarecreatedintheorderinwhichtheyaredefinedin

theapplicationcontextXMLfile.Theorderinwhichbeansarecreatedisalsodecidedbasedontheinter-

dependenciesofbeans.Forinstance,ifbeanAacceptsaninstanceofbeanBasaconstructorargument,

theSpringcontainerwillcreatebeanBbeforebeanAirrespectiveoftheorderinwhichtheyaredefined

intheapplicationcontextXMLfile.ThisbehavioroftheSpringcontainerensuresthatthedependencies

ofabean(beanBisadependencyinourexample)arecompletelyconfiguredbeforetheyareinjectedinto

thedependentbean(beanAisadependentbeaninourexample).

In some application scenarios, bean dependencies are not explicitly specified via <property> and

<constructor-arg> elements. If the bean dependencies are not explicit, you can use <bean> element’s

depends-on attribute to explicitly specify dependencies of a bean. Spring container ensures that bean

dependencies specified by the depends-on attribute are initialized before the bean that specifies the

depends-onattribute.

Let’snowlookatanexamplescenarioinwhichdepends-onattributeisusedtocontroltheinitialization

orderofbeans.

MyBank–implieddependenciesbetweenbeans

IntheMyBankapplicationofthepreviouschapter,aFactoryBeanimplementationcreatedanEventSender

objectthatwasusedbytheFixedDepositServiceImplinstancetodirectlyorindirectlystoreeventsinthe

database (refer section 3-9 of chapter 3 for details). Let’s say that instead of using a FactoryBean

implementation for creating an EventSender implementation, the approach shown in the following

diagramisadopted:

Figure4-1–EventSenderSelectorServiceImplclasswritesthenameoftheEventSenderimplementation

intheappConfig.propertiesfile,whichislaterreadbytheFixedDepositServiceImplinstance

Theabovediagramshowsthat:

·anEventSenderSelectorServiceImplclassisusedtodecideontheEventSenderimplementation

(DatabaseEventSender or WebServiceEventSender or MessagingEventSender) to be used by the

FixedDepositServiceImplclass

·        EventSenderSelectorServiceImpl class stores the fully-qualified name of the EventSender

implementationintheappConfig.propertiesfile

·        FixedDepositServiceImpl class reads the fully-qualified name of the EventSender

implementationfromtheappConfig.propertiesfile,createstheEventSenderobjectandusesitfor

storingfixeddepositeventsinthedatabase

The above approach suggests that the FixedDepositServiceImpl instance won’t work correctly if

EventSenderSelectorServiceImpl fails to save the fully-qualified name of the EventSender

implementation in the appConfig.properties file. This means that the FixedDepositServiceImpl class is

implicitlydependentontheEventSenderSelectorServiceImplclass.

Let’s now look at the implication of implicit dependence of FixedDepositServiceImpl instance on the

EventSenderSelectorServiceImplinstance.

Implicitdependencyproblem

Consider the following application context XML file that contains bean definitions for

FixedDepositServiceImplandEventSenderSelectorServiceImplclasses:

Examplelisting4-4–applicationContext.xml-Implicitdependencyexample

Project–ch04-bankapp-dependencies

Sourcelocation-src/main/resources/META-INF/spring



<beans.....>

<beanid="service"

class="sample.spring.chapter04.bankapp.service.FixedDepositServiceImpl">

.....

<constructor-argindex="0"value="META-INF/config/appConfig.properties"/>

</bean>



<beanid="eventSenderSelectorService"

class="sample.spring.chapter04.bankapp.service.EventSenderSelectorServiceImpl">

<constructor-argindex="0"value="META-INF/config/appConfig.properties"/>

</bean>

</beans>

The above application context XML file shows that both FixedDepositServiceImpl and

EventSenderSelectorServiceImplclass’sconstructoracceptlocationoftheappConfig.propertiesfile.The

EventSenderSelectorServiceImplinstanceusestheappConfig.propertiesfileforcommunicatingthefully-

qualifiednameoftheEventSenderimplementationclasstotheFixedDepositServiceImplinstance.Asan

explicit dependence doesn’t exist between service and eventSenderSelectorService beans, Spring

containercreates theirinstancesintheorder inwhich theyare defined intheapplicationcontextXML

file. As the service bean is defined before the eventSenderSelectorService bean,

FixedDepositServiceImplinstance is created before EventSenderSelectorServiceImpl instance. We’ll

soon see that if FixedDepositServiceImplinstance is created before EventSenderSelectorServiceImpl

instance,theFixedDepositServiceImplinstancewillnotbeabletoreadthenameofthefully-qualified

EventSenderimplementationclassfromtheappConfig.propertiesfile.

Let’s now take an in-depth look at the EventSenderSelectorServiceImpl and FixedDepositServiceImpl

classes,andtheappConfig.propertiesfile.

EventSenderSelectorServiceImpl–thewriter

ThefollowingexamplelistingshowstheEventSenderSelectorServiceImplclass:

Examplelisting4-5–EventSenderSelectorServiceImplclass

Project–ch04-bankapp-dependencies

Sourcelocation-src/main/java/sample/spring/chapter04/bankapp/service



packagesample.spring.chapter04.bankapp.service;



importorg.springframework.core.io.ClassPathResource;

importsample.spring.chapter04.bankapp.Constants;



publicclassEventSenderSelectorServiceImpl{



publicEventSenderSelectorServiceImpl(StringconfigFile)throwsException{

ClassPathResourceresource=newClassPathResource(configFile);

OutputStreamos=newFileOutputStream(resource.getFile());



Propertiesproperties=newProperties();

properties

.setProperty(Constants.EVENT_SENDER_CLASS_PROPERTY,

"sample.spring.chapter04.bankapp.event.DatabaseEventSender");

properties.store(os,null);

.....

}

}

TheaboveexamplelistingshowsthatthelocationofappConfig.propertiesfileispassedasaconstructor

argument to the EventSenderSelectorServiceImpl class’s constructor. The

EventSenderSelectorServiceImpl class’sconstructorwritesa property namedeventSenderClass (which

is the value of EVENT_SENDER_CLASS_PROPERTYconstant defined in the Constants class) to the

appConfig.properties file. The eventSenderClass property specifies the fully-qualified name of the

EventSender implementation to be used by the FixedDepositServiceImpl instance for directly or

indirectly saving events in the database. For the sake of simplicity, EventSenderSelectorServiceImpl

class’s constructor sets the fully-qualified name of the DatabaseEventSender class as the value of

eventSenderClassproperty.

appConfig.properties

The following is the entry that gets added to the appConfig.propertiesfile by

EventSenderSelectorServiceImplclass:

eventSenderClass=sample.spring.chapter04.bankapp.event.DatabaseEventSender

FixedDepositServiceImpl–thereader

The eventSenderClass property written by the EventSenderSelectorServiceImpl instance is read by the

FixedDepositServiceImplinstance,asshowninthefollowingexamplelisting:

Examplelisting4-6–FixedDepositServiceImplclass

Project–ch04-bankapp-dependencies

Sourcelocation-src/main/java/sample/spring/chapter04/bankapp/service



packagesample.spring.chapter04.bankapp.service;



importorg.springframework.core.io.ClassPathResource;

importsample.spring.chapter04.bankapp.Constants;



publicclassFixedDepositServiceImplimplementsFixedDepositService{

privateFixedDepositDaofixedDepositDao;

privateEventSendereventSender;



publicFixedDepositServiceImpl(StringconfigFile)throwsException{

ClassPathResourceconfigProperties=newClassPathResource(configFile);



if(configProperties.exists()){

InputStreaminStream=configProperties.getInputStream();

Propertiesproperties=newProperties();

properties.load(inStream);



StringeventSenderClassString=

properties.getProperty(Constants.EVENT_SENDER_CLASS_PROPERTY);



if(eventSenderClassString!=null){

Class<?>eventSenderClass=Class.forName(eventSenderClassString);

eventSender=(EventSender)eventSenderClass.newInstance();

logger.info("CreatedEventSenderclass");

}else{

logger.info("appConfig.propertiesfiledoesn'tcontaintheinformation"+

"aboutEventSenderclass");

}

}

}



publicvoidcreateFixedDeposit(FixedDepositDetailsfixedDepositDetails)throwsException{

.....

eventSender.sendEvent(event);

}

}

The above example listing shows following sequence of actions are performed by the constructor of

FixedDepositServiceImplclass:

·        loads properties from the appConfig.properties file. The configFile constructor argument

representsthelocationoftheappConfig.propertiesfile.

·        obtains property named eventSenderClass (represented by

EVENT_SENDER_CLASS_PROPERTY constant defined in the Constants class) from the

properties loaded fromtheappConfig.propertiesfile. The value of eventSenderClass property is

the fully-qualified name of the EventSender implementation class that FixedDepositServiceImpl

needstouse.ThevalueofeventSenderClasspropertyisstoredintheeventSenderClassStringlocal

variable.

·        creates an instance of the EventSender implementation class whose fully-qualified name is

stored in the eventSenderClassString variable, and stores the newly created instance into an

instance variable named eventSender. The eventSender variable is later used by the

FixedDepositServiceImpl’screateFixedDepositmethod(refertothecreateFixedDepositmethodin

theaboveexamplelisting)todirectlyorindirectlystoreeventsinthedatabase.

YoushouldnotethatifapropertynamedeventSenderClassisnotfoundintheappConfig.propertiesfile,

theeventSenderClassStringvariableisnot set. In this case, the FixedDepositServiceImpl’s constructor

printsthefollowingmessageontheconsole:‘appConfig.propertiesfiledoesn'tcontaintheinformation

aboutEventSenderclass’.

In example listing 4-4, we looked at bean definitions for EventSenderSelectorServiceImpl and

FixedDepositServiceImplclasses, and concluded that the FixedDepositServiceImpl instance is created

beforeEventSenderSelectorServiceImplinstancebecauseSpringcontainerinitializesbeansintheorder

inwhichtheyappearintheapplicationcontextXMLfile.Wesawinexamplelisting4-5thatthecreation

of EventSenderSelectorServiceImpl instance results in writing an eventSenderClass property to the

appConfig.properties file. So, if the FixedDepositServiceImpl instance is created before the

EventSenderSelectorServiceImpl instance, the FixedDepositServiceImpl instance will not find any

eventSenderClasspropertyintheappConfig.propertiesfile.ThisshowsthattheFixedDepositServiceImpl

class is implicitly dependent on the EventSenderSelectorServiceImpl class; therefore, the

EventSenderSelectorServiceImplinstancemustbecreatedbeforetheFixedDepositServiceImplinstance.

Howtoaddressimplicitdependencyproblem?

Wecansolvetheimplicitdependencyproblemintwoways:

·        we change the order in which bean definitions for EventSenderSelectorServiceImpl and

FixedDepositServiceImpl classes are defined in the application context XML file. If the bean

definitionfortheEventSenderSelectorServiceImplclassappearsbeforethebeandefinitionforthe

FixedDepositServiceImpl class, the EventSenderSelectorServiceImpl instance will be created

beforetheFixedDepositServiceImplinstance.

·        use <bean> element’s depends-on attribute to explicitly specify that the service bean

(corresponding to the FixedDepositServiceImpl class) is dependent on the

eventSenderSelectorServicebean(correspondingtotheEventSenderSelectorServiceImplclass).

Thefollowingexamplelistingshowstheusageof<bean>element’sdepends-onattribute:



Examplelisting4-7–<bean>element’sdepends-onattribute



<beans.....>

<beanid="service"

class="sample.spring.chapter04.bankapp.service.FixedDepositServiceImpl"

depends-on="eventSenderSelectorService">

.....

</bean>



<beanid="eventSenderSelectorService"

class="sample.spring.chapter04.bankapp.service.EventSenderSelectorServiceImpl">

.....

</bean>

</beans>

In the above example listing, the service bean uses depends-on attribute to explicitly specify that it is

dependentontheeventSenderSelectorServicebean.Thedepends-onattributespecifiestheidsornames

of the beans on which the bean is dependent. As the service bean specifies that it is dependent on the

eventSenderSelectorService bean, Spring container creates eventSenderSelectorService bean

(corresponding to the EventSenderSelectorServiceImpl class) instance before service bean

(correspondingtotheFixedDepositServiceImplclass)instance.

NOTE If you execute the main method of the BankApp class of ch04-bankapp-dependencies project,

you’ll find that the FixedDepositServiceImpl instance is created before EventSenderSelectServiceImpl

instance. For this reason, the following message is printed on the console: ‘appConfig.properties file

doesn'tcontaintheinformationaboutEventSenderclass’.

Multipleimplicitdependencies

Ifabeanhasmultipleimplicitdependencies,youcanspecifyidsornamesofallthosedependenciesas

thevalueofdepends-onattribute,asshownhere:

Examplelisting4-8–depends-onattributeexample-multipleimplicitdependencies



<beans.....>

<beanid="abean".....depends-on="bBean,cBean">

.....

</bean>

.....

</beans>

Theaboveexamplelistingshowsthatyoucanspecifymultiplebeanidsornamesasthevalueofdepends-

onattribute.

depends-onattributeandbeandefinitioninheritance

It is important to note that the depends-on attribute is not inherited by child bean definitions. The

following example listing shows an abstract serviceTemplate parent bean definition that uses the

depends-onattributetospecifybaseServicebeanasadependency:

Examplelisting4-9–depends-onattribute–beandefinitioninheritance



<beanid="serviceTemplate"class=".....ServiceTemplate"depends-on="baseService"

abstract="true"/>



<beanid="someService"class=".....SomeServiceImpl"parent="serviceTemplate"/>



<beanid="someOtherService"class=".....SomeOtherServiceImpl"parent="serviceTemplate"/>



<beanid="baseService"class=".....BaseServiceImpl"/>

Intheaboveexamplelisting,someServiceandsomeOtherServicechildbeandefinitionsdon’tinheritthe

depends-on attribute from the serviceTemplate parent bean definition. As the Spring container creates

beansintheorderinwhichtheyaredefinedintheapplicationcontextXMLfile,thebaseServicebeanis

createdafterthecreationofsomeServiceandsomeOtherServicebeans.

Let’s now look at how the Spring container manages dependencies of singleton- and prototype-scoped

beans.

4-4Singleton-andprototype-scopedbean’sdependencies

Asingleton-scopedbean(anditssingleton-scopeddependencies)iscreatedwhentheApplicationContext

instance is created. And, a prototype-scoped bean (and its prototype-scoped dependencies) is created

eachtimeApplicationContext’sgetBeanmethodisinvokedtoobtaintheprototype-scopedbean.

If a singleton-scoped bean is dependent on a prototype-scoped bean, or vice versa, things get a bit

complicated.Forinstance,ifasingleton-scopedbeanisdependentonaprototype-scopedbean,youmight

ask the question whether the Spring container will create the prototype-scoped bean (the dependency)

beforethesingleton-scopedbean(thedependentbean)?ortheSpringcontainerwillcreateandinjectthe

prototype-scopedbeaninstanceonlywhenyoucalltheApplicationContext’sgetBeanmethodtoretrieve

the singleton-scoped bean instance? The answers to these questions lies in the way singleton- and

prototype-scopeddependenciesofabeanaremanagedbytheSpringcontainer,asexplainednext.

Singleton-scopedbean’sdependencies

The following example listing shows the singleton-scoped customerRequestService bean of MyBank

application,anditsdependencies:

Examplelisting4-10–applicationContext.xml-DependenciesofcustomerRequestServicebean

Project–ch04-bankapp-dependencies

Sourcelocation-src/main/resources/META-INF/spring



<beanid="customerRequestService"

class="sample.spring.chapter04.bankapp.service.CustomerRequestServiceImpl">

<constructor-argname="customerRequestDetails"ref="customerRequestDetails"/>

<constructor-argname="customerRequestDao"ref="customerRequestDao"/>

</bean>



<beanid="customerRequestDetails"

class="sample.spring.chapter04.bankapp.domain.CustomerRequestDetails"

scope="prototype"/>



<beanid="customerRequestDao"

class="sample.spring.chapter04.bankapp.dao.CustomerRequestDaoImpl"/>

TheaboveexamplelistingshowsthatthecustomerRequestService (singleton-scoped)beandepends on

customerRequestDetails (prototype-scoped) and customerRequestDao (singleton-scoped) beans.

CustomerRequestServiceobject(representedbythecustomerRequestServicebean)representsaservice

that is invoked when a bank customer creates a new request, like a cheque book request.

CustomerRequestServiceputsthedetailsofthecustomerrequestintoaCustomerRequestDetails object

(represented by the customerRequestDetails bean) and saves it in the data store using

CustomerRequestDaoobject(representedbythecustomerRequestDaobean).

ThefollowingexamplelistingshowsthemainmethodofBankAppclassthatloadsthebeandefinitions

showninexamplelisting4-10:

Examplelisting4-11–BankAppclass

Project–ch04-bankapp-dependencies

Sourcelocation-src/main/java/sample/spring/chapter04/bankapp



packagesample.spring.chapter04.bankapp;



importorg.springframework.context.ApplicationContext;

importorg.springframework.context.support.ClassPathXmlApplicationContext;



publicclassBankApp{

privatestaticLoggerlogger=Logger.getLogger(BankApp.class);



publicstaticvoidmain(Stringargs[])throwsException{

ApplicationContextcontext=newClassPathXmlApplicationContext(

"classpath:META-INF/spring/applicationContext.xml");

.....

logger.info("BeginningwithaccessingCustomerRequestService");

CustomerRequestServicecustomerRequestService_1

=context.getBean(CustomerRequestService.class);

.....

CustomerRequestServicecustomerRequestService_2

=context.getBean(CustomerRequestService.class);

.....

logger.info("DonewithaccessingCustomerRequestService");

}

}

The above example listing shows that after the ApplicationContext instance is created,

ApplicationContext’sgetBeanmethodisinvokedtwicetoobtainreferencetothecustomerRequestService

bean.

IfyouexecutethemainmethodoftheBankAppclass,you’llseethefollowingoutput:

CreatedCustomerRequestDetailsinstance

CreatedCustomerRequestDaoImplinstance

CreatedCustomerRequestServiceImplinstance

.....

BeginningwithaccessingCustomerRequestService

DonewithaccessingCustomerRequestService

The‘Created.....’messagesshownintheaboveoutputareprintedbytheconstructorsoftherespective

bean classes. The above output shows that the customerRequestDetails (prototype-scoped) and

customerRequestDao(singleton-scoped)dependenciesofthecustomerRequestService(singleton-scoped)

bean are created and injected into the customerRequestService instance when the Spring container is

created.Asno‘Created.....’message was printed on the console between‘Beginning.....’ and ‘Done

.....’ messages, no bean instances were created by the Spring container when ApplicationContext’s

getBeanmethodwasinvokedtoretrievethecustomerRequestServicebean.

Figure4-2showsthesequencediagramthatdepictsthesequenceofeventsthatoccurwhenBankApp’s

main method (refer example listing 4-11) is executed. Figure 4-2 shows that when Spring container is

created, the customerRequestDetails (prototype-scoped) and customerRequestDao (singleton-scoped)

beansarefirstcreated,followedbycreationofcustomerRequestService(singleton-scoped).Constructor-

based DI is used to inject the customerRequestDetails and customerRequestDao beans into the

customerRequestServicebean.Asasingleton-scopedbeaniscreatedonlyoncebytheSpringcontainer,

theSpringcontainerhasonlyoneopportunitytoinjectcustomerRequestServicebean’sdependencies.For

thisreason,theSpringcontainerinjectsprototype-scopedcustomerRequestDetailsbeaninstanceintothe

customerRequestService bean only once. The implication of this behavior is that the

customerRequestServicebeanendsupholdingreferencetothesamecustomerRequestDetailsbeanduring

itslifetime.

Figure 4-2 - The sequence of events that occur when the Spring container is created and the

customerRequestServicebeanisretrievedfromtheSpringcontainer

It is important to note that even if setter-based DI was used to inject the prototype-scoped

customerRequestDetails dependency of the customerRequestService bean, the Spring container would

have called the setter method onlyonce during the lifetime of the customerRequestService bean. This

meansthatirrespectiveofwhethersetter-orconstructor-basedDIisused,asingletonbeaniscreatedand

configuredonlyonceduringit’slifetime.

Now,oncetheSpringcontaineriscreated,anyrequestforthesingleton-scopedcustomerRequestService

beanreturnsthesamecachedinstanceofthecustomerRequestServicebean.Forthisreason,no‘Created

.....’messagewaswrittenouttotheconsolebetween‘Beginning.....’and‘Done.....’messageswhenwe

executedBankApp’smainmethod(referexamplelisting4-11).

As the singleton-scoped customerRequestService bean always holds reference to the same prototype-

scopedcustomerRequestDetailsbean, itmay adversely affectthe behavior ofMyBank application.For

instance, if multiple customers simultaneously submit request to the CustomerRequestServiceImpl

instance,alltherequestswillresultinmodifyingthesameinstanceoftheCustomerRequestDetailsobject

heldbytheCustomerRequestService.Ideally,CustomerRequestServiceImplshouldcreateanewinstance

ofCustomerRequestDetailsobjectoneveryrequest.Insection4-5,we’llseewhatmodificationsweneed

tomaketothebeanclassofasingleton-scopedbeansothatitcanretrieveanewinstanceofaprototype-

scopedbeanoneverymethodcall.

Let’snowlookathowtheSpringcontainermanagesprototype-andsingleton-scopeddependenciesofa

prototype-scopedbean.

Prototype-scopedbean’sdependencies

In MyBank, a customer registers with the MyBank application by following a sequence of steps. For

instance, a customer first enters personal information and his account details, and if the MyBank

application finds a matching record, the customer is asked for his debit card details. The

CustomerRegistrationServiceImplclassofMyBankapplicationcontainsthenecessarybusinesslogicto

theCustomerRegistrationServiceImplobjectmaintainsconversationalstatebetweenmethodcalls.

The following example listing shows the prototype-scoped customerRegistrationService bean

(representingtheCustomerRegistrationServiceImplclass)ofMyBankapplication,anditsdependencies:

Examplelisting4-12–applicationContext.xml-customerRegistrationServicebeananditsdependencies

Project–ch04-bankapp-dependencies

Sourcelocation-src/main/resources/META-INF/spring



<beanid="customerRegistrationService"

class="sample.spring.chapter04.bankapp.service.CustomerRegistrationServiceImpl"

scope="prototype">

<constructor-argname="customerRegistrationDetails"ref="customerRegistrationDetails"/>

<constructor-argname="customerRegistrationDao"ref="customerRegistrationDao"/>

</bean>

<beanid="customerRegistrationDetails"

class="sample.spring.chapter04.bankapp.domain.CustomerRegistrationDetails"

scope="prototype"/>



<beanid="customerRegistrationDao"

class="sample.spring.chapter04.bankapp.dao.CustomerRegistrationDaoImpl"/>

TheaboveexamplelistingshowsthatthecustomerRegistrationService(prototype-scoped)beandepends

on customerRegistrationDetails (prototype-scoped) and customerRegistrationDao (singleton-scoped)

beans.

CustomerRegistrationServiceImpl instance maintains progress of the registration process, and stores

information provided by the customer during the registration process in a CustomerRegistrationDetails

object(representedbythecustomerRegistrationDetailsbean).AsbothCustomerRegistrationServiceImpl

and CustomerRegistrationDetails objects are stateful in nature, both customerRegistrationService and

customerRegistrationDetailsbeansaredefinedasprototype-scopedbeans.

ThefollowingexamplelistingshowsthemainmethodofBankAppclassthatloadscustomerregistration

relatedbeans(referexamplelisting4-12)andperformsregistrationsfor2customers:

Examplelisting4-13–BankAppclass

Project–ch04-bankapp-dependencies

Sourcelocation-src/main/java/sample/spring/chapter04/bankapp



packagesample.spring.chapter04.bankapp;



importorg.springframework.context.ApplicationContext;

importorg.springframework.context.support.ClassPathXmlApplicationContext;



publicclassBankApp{

privatestaticLoggerlogger=Logger.getLogger(BankApp.class);



publicstaticvoidmain(Stringargs[])throwsException{

ApplicationContextcontext=newClassPathXmlApplicationContext(

"classpath:META-INF/spring/applicationContext.xml");

.....

logger.info("BeginningwithaccessingCustomerRegistrationService");



CustomerRegistrationServicecustomerRegistrationService_1=context

.getBean(CustomerRegistrationService.class);

customerRegistrationService_1.setAccountNumber("account_1");

customerRegistrationService_1.setAddress("address_1");

customerRegistrationService_1.setDebitCardNumber("debitCardNumber_1");

customerRegistrationService_1.register();

logger.info("registeredcustomerwithidaccount_1");



CustomerRegistrationServicecustomerRegistrationService_2=context

.getBean(CustomerRegistrationService.class);



.....

logger.info("registeredcustomerwithidaccount_2");

logger.info("DonewithaccessingCustomerRegistrationService");

}

}

The above example listing shows that the BankApp’smain method calls ApplicationContext’s getBean

method twice to obtain reference to customerRegistrationService bean. Once the

customerRegistrationService bean instance is retrieved, the setAccountNumber, setAddress,

setDebitCardNumber and register methods are invoked on it. If you execute BankApp’s main method,

you’llseethefollowingoutputontheconsole:

CreatedCustomerRegistrationDaoImplinstance

.....

BeginningwithaccessingCustomerRegistrationService

CreatedCustomerRegistrationDetailsinstance

CreatedCustomerRegistrationServiceImplinstance

registeredcustomerwithidaccount_1

CreatedCustomerRegistrationDetailsinstance

CreatedCustomerRegistrationServiceImplinstance

registeredcustomerwithidaccount_2

DonewithaccessingCustomerRegistrationService

The‘Created.....’messagesshownintheaboveoutputareprintedbytheconstructorsoftherespective

bean classes. The above output shows that the singleton-scoped customerRegistrationDao bean

(representingtheCustomerRegistrationDaoImplclass)iscreatedonlyoncewhentheApplicationContext

instance is created. The ‘Created.....’ messages between ‘Beginning.....’ and ‘Done.....’ messages

indicatethateachtimeApplicationContext’sgetBeanmethod isinvokedto obtaintheprototype-scoped

customerRegistrationService bean, a new instance of the customerRegistrationService bean and its

prototype-scopeddependency(thecustomerRegistrationDetailsbean)iscreatedbytheSpringcontainer.

Figure4-3showsthesequencediagramthatdepictsthesequenceofeventsthatoccurwhenBankApp’s

main method (refer example listing 4-13) is executed. The figure shows that the singleton-scoped

customerRegistrationDaobeaniscreatedonlyoncewhenApplicationContextinstanceiscreated.When

theprototype-scopedcustomerRegistrationServicebeanisrequestedfromtheSpringcontainer,theSpring

container first creates an instance of customerRegistrationDetails bean (which is the prototype-scoped

dependency of the customerRegistrationService bean), followed by the creation of the

customerRegistrationServicebean.Thisshowsthatifaprototype-scopedbeanXisdependentonanother

prototype-scopedbeanY,SpringcontainerwillcreateanewinstanceofXandYeachtimeyourequest

beanXfromtheSpringcontainer.

Figure 4-3 – The sequence of events that occur when the Spring container is created and the

customerRegistrationServicebeanisretrievedfromtheSpringcontainer

Earlierinthissection,wesawthatifasingleton-scopedbeanisdependentonaprototype-scopedbean,

then throughout its lifetime the singleton-scoped bean is associated with the same instance of the

prototype-scopedbean.Let’snowlookatdifferentwaysinwhichasingleton-scopedbeancanretrievea

newinstanceofaprototype-scopedbeanfromtheSpringcontainer.

4-5Obtainingnewinstancesofprototypebeansinsidesingletonbeans

In the previous section, we saw that the prototype-scoped dependency of a singleton-scoped bean is

injectedatthetimeofcreationofthesingleton-scopedbean(referfigure4-2).Springcontainercreates

instanceofasingleton-scopedbeanonlyonce;therefore,thesingleton-scopedbeanholdsreferencetothe

sameprototype-scopedbeaninstanceduringitslifetime.Asingleton-scopedbean’smethodscanretrieve

a new instance of their prototype-scoped dependency from the Spring container using any one of the

followingapproaches:

·makethesingleton-scopedbean’sclassimplementSpring’sApplicationContextAwareinterface

·usethe<lookup-method>elementofSpring’sbeansschema

·usethe<replaced-method>elementofSpring’sbeansschema

NOTEItispossibletousethenewkeywordtocreateaninstanceoftheprototype-scopedbean’sclassin

asingleton-scopedbean’smethodanduseit.Astheresponsibilityofcreatingabeaninstanceiswiththe

Springcontainer,weshouldnotattempttodirectlycreateabeaninstanceusingthenewkeyword.

IMPORTchapter4/ch04-bankapp-context-aware(Thisprojectshowsascenarioinwhichasingleton-

scopedbeanimplementsSpring’sApplicationContextAwareinterfacetoobtaininstancesofaprototype-

scopedbeanfromtheSpringcontainer.Toruntheapplication,executethemainmethodoftheBankApp

classofthisproject)

Let’sfirstbeginbylookingattheApplicationContextAwareinterface.

ApplicationContextAwareinterface

Spring’s ApplicationContextAware interface is implemented by beans that require access to the

ApplicationContext instance in which they are running. ApplicationContextAware interface defines a

single method, setApplicationContext, which provides the implementing beans with an instance of the

ApplicationContextobject.

ApplicationContextAwareinterfaceisalifecycleinterface,whichmeansthattheSpringcontainercalls

thebeansimplementingtheApplicationContextAwareinterfaceatappropriatetimesduringtheirlifetime.

Forinstance,ApplicationContextAware’ssetApplicationContextmethodiscalledbytheSpringcontainer

afterthebeaninstanceiscreatedbutbeforethebeaninstanceiscompletelyinitialized.Abeaninstanceis

consideredcompletelyinitializedonlyafteritsinitializationmethod(refersection5-2ofchapter5)is

calledbytheSpringcontainer.Itisimportanttonotethatafterabeaninstanceiscompletelyinitialized,it

is injected into the dependent bean instances by the Spring container. In chapter 5, we’ll look at some

morelifecycleinterfacesinSpring.

AbeanthatimplementstheApplicationContextAwareinterfacecanaccessotherbeansregisteredwiththe

ApplicationContextinstancebycallingApplicationContext’sgetBeanmethod.Thismeansthatifthebean

class of a singleton-scoped bean implements ApplicationContextAware interface, it can fetch a new

instanceofaprototype-scopedbeanfromtheSpringcontainerbycallingApplicationContext’sgetBean

method.Asthesingleton-scopedbeanexplicitlyobtainsitsprototype-scopeddependencyfromtheSpring

containerbycallingApplicationContext’sgetBeanmethod,youdon’tneedtodefinetheprototype-scoped

beanasadependencyofthesingleton-scopedbeanintheapplicationcontextXMLfile.

ThefollowingexamplelistingshowstheCustomerRequestServiceImplclassthatneedsanewinstanceof

CustomerRequestDetails object each time CustomerRequestServiceImpl’s submitRequest method is

called:

Examplelisting4-14–CustomerRequestServiceImplclass

Project–ch04-bankapp-context-aware

Sourcelocation-src/main/java/sample/spring/chapter04/bankapp/service



packagesample.spring.chapter04.bankapp.service;



importsample.spring.chapter04.bankapp.dao.CustomerRequestDao;

importsample.spring.chapter04.bankapp.domain.CustomerRequestDetails;



publicclassCustomerRequestServiceImplimplementsCustomerRequestService{

privateCustomerRequestDetailscustomerRequestDetails;

privateCustomerRequestDaocustomerRequestDao;



@ConstructorProperties({"customerRequestDetails","customerRequestDao"})

publicCustomerRequestServiceImpl(CustomerRequestDetailscustomerRequestDetails,

CustomerRequestDaocustomerRequestDao){

this.customerRequestDetails=customerRequestDetails;

this.customerRequestDao=customerRequestDao;

}



publicvoidsubmitRequest(StringrequestType,StringrequestDescription){

//--populateCustomerRequestDetailsobjectandsaveit

customerRequestDetails.setType(requestType);

customerRequestDetails.setDescription(requestDescription);

customerRequestDao.submitRequest(customerRequestDetails);

}

}

TheaboveexamplelistingshowsthattheCustomerRequestDetailsandCustomerRequestDaoobjectsare

passedasargumentstotheCustomerRequestServiceImplclass’sconstructor.ThesubmitRequestmethod

populates the CustomerRequestDetails instance and saves it into the database by calling

CustomerRequestDao’ssubmitRequest method.Ifmultiplecustomers simultaneouslysubmitrequest, the

submitRequest method will end up modifying the same instance of the CustomerRequestDetails object,

resulting in undesired behavior of MyBank application. To address this issue, the submitRequest must

obtainanewinstanceoftheCustomerRequestDetailsobjectfromtheSpringcontaineroneachinvocation.

The following example listing shows the CustomerRequestServiceContextAwareImpl class (a modified

versionofCustomerRequestServiceImplclassthatwesawinexamplelisting4-14)thatimplementsthe

ApplicationContextAwareinterface:

Example listing 4-15 – CustomerRequestServiceContextAwareImpl class that implements Spring’s

ApplicationContextAwareinterface

Project–ch04-bankapp-context-aware

Sourcelocation-src/main/java/sample/spring/chapter04/bankapp/service



packagesample.spring.chapter04.bankapp.service;



importorg.springframework.context.ApplicationContext;

importorg.springframework.context.ApplicationContextAware;



publicclassCustomerRequestServiceContextAwareImplimplements

CustomerRequestService,ApplicationContextAware{



privateCustomerRequestDaocustomerRequestDao;

privateApplicationContextapplicationContext;



@ConstructorProperties({"customerRequestDao"})

publicCustomerRequestServiceContextAwareImpl(CustomerRequestDaocustomerRequestDao)

{

this.customerRequestDao=customerRequestDao;

}



publicvoidsetApplicationContext(ApplicationContextapplicationContext)

throwsBeansException{

this.applicationContext=applicationContext;

}



publicvoidsubmitRequest(StringrequestType,StringrequestDescription){

CustomerRequestDetailscustomerRequestDetails=applicationContext

.getBean(CustomerRequestDetails.class);

customerRequestDetails.setType(requestType);

customerRequestDetails.setDescription(requestDescription);

customerRequestDao.submitRequest(customerRequestDetails);

}

}

In the above example listing, setApplicationContext method provides

CustomerRequestServiceContextAwareImpl with an instance of ApplicationContext object. The

ApplicationContext instance is later used by the submitRequest method to obtain an instance of

CustomerRequestDetailsobjectfromtheSpringcontainer.

As the CustomerRequestServiceContextAwareImpl class explicitly obtains CustomerRequestDetails

object from the Spring container, you don’t need to use Spring’s DI mechanism to inject

CustomerRequestDetails instance intotheCustomerRequestServiceContextAwareImpl instance. For this

reason, CustomerRequestServiceContextAwareImpl class’s constructor (refer example listing 4-15)

doesn’tspecifyCustomerRequestDetailsobjectasanargument.Ifyounowgotoch04-bankapp-context-

awareprojectandexecuteBankApp’smainmethod,you’llfindthatoneachinvocationofsubmitRequest

methodanewinstanceofCustomerRequestDetailsobjectisfetchedfromtheSpringcontainer.

InthecontextofMyBank,wesawthattheApplicationContextAwareinterfaceisusefulifabeanrequires

access to other beans. The downside of implementing the ApplicationContextAware interface is that it

couples your bean class to Spring Framework. You can avoid coupling your bean classes with Spring

FrameworkandstillaccessotherbeansfromtheSpringcontainerbyusingmethodinjectiontechniques

offeredby<lookup-method>and<replaced-method>elementsofSpring’sbeansschema.

Let’sfirstlookatthe<lookup-method>element.

IMPORT chapter 4/ch04-bankapp-lookup-method (This project shows the MyBank application that

uses<lookup-method>elementofSpring’sbeansschema.Toruntheapplication,executethemainmethod

oftheBankAppclassofthisproject)

<lookup-method>element

Ifabeanclassdefinesabeanlookupmethodwhosereturntyperepresentsabean,the<lookup-method>

element instructs the Spring container to provide implementation for this method. The method

implementationprovidedbytheSpringcontainerisresponsibleforretrievingthebeaninstancefromthe

Springcontainerandreturningit.

The <lookup-method> element’s bean attribute specifies the name of the bean to be looked-up and

returnedbythemethodimplementation,andthenameattribute specifies the nameof themethodwhose

implementation is to be provided by the Spring container. It is important to note that the bean lookup

methoddefinedbythebeanclasscanbeanabstractoraconcretemethod.

NOTETheuseof<lookup-method>elementtoinstructtheSpringcontainertoprovideimplementation

forabeanlookupmethodisreferredtoasa‘MethodInjectiontechinique’becausethe<lookup-method>

elementinjectsabeanlookupmethodimplementationintothebeanclass.

The following example listing shows CustomerRequestServiceImpl’s getCustomerRequestDetails

abstractmethodthatreturnsaninstanceofCustomerRequestDetailsinstance:

Examplelisting4-16–CustomerRequestServiceImplclass–definingabeanlookupmethod

Project–ch04-bankapp-lookup-method

Sourcelocation-src/main/java/sample/spring/chapter04/bankapp/service



packagesample.spring.chapter04.bankapp.service;



publicabstractclassCustomerRequestServiceImplimplementsCustomerRequestService{

privateCustomerRequestDaocustomerRequestDao;



@ConstructorProperties({"customerRequestDao"})

publicCustomerRequestServiceImpl(CustomerRequestDaocustomerRequestDao){

this.customerRequestDao=customerRequestDao;

}



publicabstractCustomerRequestDetailsgetCustomerRequestDetails();



@Override

publicvoidsubmitRequest(StringrequestType,StringrequestDescription){

//--populateCustomerRequestDetailsobjectandsaveit

CustomerRequestDetailscustomerRequestDetails=getCustomerRequestDetails();

.....

}

}

The above example listing shows that the CustomerRequestServiceImpl class is defined as abstract

becauseitcontainsanabstractbeanlookupmethod,getCustomerRequestDetails.Insteadofabstract,we

could have very well defined the getCustomerRequestDetails method as a concrete method. The

submitRequest method invokes the getCustomerRequestDetails method to access a

CustomerRequestDetailsinstance.

The following example listing shows bean definitions for CustomerRequestServiceImpl and

CustomerRequestDetailsclasses:

Examplelisting4-17–applicationContext.xml-<lookup-method>elementusage

Project–ch04-bankapp-lookup-method

Sourcelocation-src/main/resources/META-INF/spring

<beanid="customerRequestService"

class="sample.spring.chapter04.bankapp.service.CustomerRequestServiceImpl">

<constructor-argname="customerRequestDao"ref="customerRequestDao"/>

<lookup-methodbean="customerRequestDetails"name="getCustomerRequestDetails"/>

</bean>



<beanid="customerRequestDetails"

class="sample.spring.chapter04.bankapp.domain.CustomerRequestDetails"

scope="prototype"/>

The above example listing shows that the bean definition for the CustomerRequestServiceImpl class

contains a <lookup-method> element. The value of <lookup-method> element’s name attribute is

getCustomerRequestDetails, which instructs the Spring container to provide implementation for the

getCustomerRequestDetailslookupmethod(referexamplelisting4-16)ofCustomerRequestServiceImpl

class.Thevalueof<lookup-method> element’s beanattributeiscustomerRequestDetails, which means

that the implementation of getCustomerRequestDetails method retrieves a bean with id (or name) as

customerRequestDetails from the Spring container and returns it to the calling method. As the

customerRequestDetails bean represents a CustomerRequestDetails object (refer to the

customerRequestDetails bean definition in example listing 4-17), the implementation of

getCustomerRequestDetailsmethodreturnsaCustomerRequestDetailsobject.

In example listing 4-16, the CustomerRequestService’s submitRequest method invokes the

getCustomerRequestDetails bean lookup method to obtain a CustomerRequestDetails instance. As

CustomerRequestDetailsclassisrepresentedasaprototype-scopedbeanintheapplicationcontextXML

file (refer example listing4-17), each invocation of thesubmitRequest methodresultsin retrieval ofa

newinstanceofCustomerRequestDetailsobjectfromtheSpringcontainer.

To check that the <lookup-method> element provides correct implementation for the

CustomerRequestService’s getCustomerRequestDetails bean lookup method, the main method of

BankAppclassobtainsaninstanceofCustomerRequestServicefromtheSpringcontainerandinvokesits

submitRequestmethodmultipletimes.IfeachinvocationofthesubmitRequestmethodresultsinretrieval

of a fresh instance of CustomerRequestDetails object from the Spring container, then it means that the

<lookup-method> element provides correct implementation for the CustomerRequestService’s

getCustomerRequestDetailsmethod.

ThefollowingexamplelistingshowstheBankApp’smainmethodthatinvokesCustomerRequestService’s

submitRequestmethodmultipletimes:

Examplelisting4-18–BankAppclass

Project–ch04-bankapp-lookup-method

Sourcelocation-src/main/java/sample/spring/chapter04/bankapp



packagesample.spring.chapter04.bankapp;

.....

publicclassBankApp{

privatestaticLoggerlogger=Logger.getLogger(BankApp.class);



publicstaticvoidmain(Stringargs[])throwsException{

ApplicationContextcontext=newClassPathXmlApplicationContext(

"classpath:META-INF/spring/applicationContext.xml");

.....

logger.info("BeginningwithaccessingCustomerRequestService");

CustomerRequestServicecustomerRequestService_1=context

.getBean(CustomerRequestService.class);

customerRequestService_1.submitRequest("checkBookRequest",

"Requesttosenda50-leafcheckbook");

customerRequestService_1.submitRequest("checkBookRequest",

"Requesttosenda100-leafcheckbook");

.....

logger.info("DonewithaccessingCustomerRequestService");

}

}

IfyouexecutetheBankApp’smainmethod,you’llseethefollowingoutputontheconsole:

BeginningwithaccessingCustomerRequestService

CreatedCustomerRequestDetailsinstance

.....

DonewithaccessingCustomerRequestService

The‘Created.....’messagesshownintheaboveoutputareprintedbytheconstructorsoftherespective

beanclasses.TheaboveoutputshowsthateachinvocationofCustomerRequestService’ssubmitRequest

methodresultedinretrievalofanewCustomerRequestDetailsinstancefromtheSpringcontainer.

AstheimplementationofthebeanlookupmethodisprovidedbytheSpringcontainer,somerestrictions

applytothesignatureofthebeanlookupmethods.Forinstance,thebeanlookupmethodmustbedefined

aspublicorprotected,anditmustnotacceptanyarguments.Asthebeanclasscontainingthebeanlookup

methodissubclassedatruntimebytheSpringcontainertoprovidetheimplementationforthebeanlookup

method,thebeanclassandthebeanlookupmethodmustnotbedefinedasfinal.

NOTE As the bean class containing the bean lookup method needs to be subclassed at runtime by the

Springcontainertoprovideimplementationforthebeanlookupmethod,theSpringcontainerusesCGLIB

(http://cglib.sourceforge.net/)librarytoperformsubclassingofthebeanclass.StartingwithSpring3.2,

the CGLIB classes are packaged within the spring-core JAR file itself; therefore, you don’t need to

explicitlyspecifythatyourprojectisdependentonCGLIBJARfile.

The<lookup-method> element provides a method injection technique in which a bean class defines a

beanlookupmethodwhoseimplementationisprovidedbytheSpringcontainer.Insteadofusing<lookup-

method> element, you can consider using <replaced-method> element of Spring’s beans schema to

performmethodinjection.

IMPORTchapter4/ch04-bankapp-replaced-method(ThisprojectshowstheMyBankapplicationthat

uses <replaced-method> element of Spring’s beans schema. To run the application, execute the main

methodoftheBankAppclassofthisproject)

<replaced-method>element

The<replaced-method>elementallowsyoutoreplaceanyarbitrarymethodinabeanclass

with a different implementation. The following example listing shows the

CustomerRequestServiceImpl class that we’ll be using as an example to demonstrate use of

<replaced-method>element:

Examplelisting4-19–CustomerRequestServiceImplclass

Project–ch04-bankapp-replaced-method

Sourcelocation-src/main/java/sample/spring/chapter04/bankapp/service



packagesample.spring.chapter04.bankapp.service;

.....

publicclassCustomerRequestServiceImplimplementsCustomerRequestService{

privateCustomerRequestDaocustomerRequestDao;

.....

publicObjectgetMyBean(StringbeanName){

returnnull;

}



@Override

publicvoidsubmitRequest(StringrequestType,StringrequestDescription){

//--populateCustomerRequestDetailsobjectandsaveit

CustomerRequestDetailscustomerRequestDetails=

(CustomerRequestDetails)getMyBean("customerRequestDetails");

customerRequestDetails.setType(requestType);

customerRequestDetails.setDescription(requestDescription);

customerRequestDao.submitRequest(customerRequestDetails);

}

}

The above example listing shows that the CustomerRequestServiceImpl class defines a getMyBean

method.ThegetMyBeanmethodacceptsnameofabeanasanargument,andinsteadofreturningthebean

instance corresponding to the bean name argument, the getMyBean method returns null. The

submitRequestmethodpassescustomerRequestDetailsstringasargumenttothegetMyBeanmethodand

assumes that the getMyBean method returns an instance of customerRequestDetails bean. Using

<replaced-method>element,youcanoverridethegetMyBeanmethodwithamethodthatreturnsthebean

instancecorrespondingtothebeannameargument.

The <replaced-method> element needs information about the overridden method (which is

CustomerRequestServiceImpl getMyBean method in our example scenario) and the overriding method.

TheoverridingmethodisprovidedbytheclassthatimplementsSpring’sMethodReplacerinterface.The

following example listing shows MyMethodReplacer class that implements the MethodReplacer

interface:

Examplelisting4-20–MyMethodReplacerclass

Project–ch04-bankapp-replaced-method

Sourcelocation-src/main/java/sample/spring/chapter04/bankapp/service



packagesample.spring.chapter04.bankapp.service;



importorg.springframework.beans.factory.support.MethodReplacer;

importorg.springframework.context.ApplicationContextAware;



publicclassMyMethodReplacerimplementsMethodReplacer,ApplicationContextAware{

privateApplicationContextapplicationContext;



@Override

publicObjectreimplement(Objectobj,Methodmethod,Object[]args)throwsThrowable{

returnapplicationContext.getBean((String)args[0]);

}



@Override

publicvoidsetApplicationContext(ApplicationContextapplicationContext)

throwsBeansException{

this.applicationContext=applicationContext;

}

}

Spring’sMethodReplacerinterfacedefinesareimplementmethodwhoseimplementationisprovidedby

the MyMethodReplacer class. The reimplement method represents the overriding method.

MyMethodReplacer class also implements Spring’s ApplicationContextAware interface so that the

reimplement method can access the ApplicationContext instance. The reimplement method uses the

ApplicationContext’sgetBeanmethodtoretrievebeansfromtheSpringcontainer.

Thereimplementmethodacceptsthefollowingarguments:

·Objectobj–identifiestheobjectwhosemethodweareoverriding.Inourexamplescenario,the

objobjectistheCustomerRequestServiceImplobject.

·        Methodmethod – identifies the bean class’s method that is overridden by the reimplement

method.Inourexamplescenario,thisisCustomerRequestServiceImpl’sgetMyBeanmethod.

·Object[]args–identifiesargumentspassedtothemethodthatweareoverriding.Inourexample

scenario,args represents the arguments passed to the CustomerRequestServiceImpl’s getMyBean

method.Inexamplelisting4-20,args[0]inthereimplementmethodrefersthebeannameargument

passedtotheCustomerRequestServiceImpl’sgetMyBeanmethod.

IfyounowlookatMyMethodReplacer’sreimplementmethodinexamplelisting4-20,youcaninferthatit

usesargs argument to first obtain bean name passed to the CustomerRequestServiceImpl’s getMyBean

method,andthencallsApplicationContext’sgetBeanmethodtoobtainthecorrespondingbeaninstance.

As MyMethodReplacer’s reimplement method overrides CustomerRequestServiceImpl’s getMyBean

method,calltogetMyBeanmethod at runtime returns thebeaninstance whose name was passed tothe

getMyBeanmethod.

The <replaced-method> element informs the Spring container that MyMethodReplacer’s reimplement

methodoverridesCustomerRequestServiceImpl’sgetMyBeanmethod,asshowninthefollowingexample

listing:

Examplelisting4-21–applicationContext.xml-<replaced-method>elementusage

Project–ch04-bankapp-replaced-method

Sourcelocation-src/main/resources/META-INF/spring

<beanid="customerRequestService"

class="sample.spring.chapter04.bankapp.service.CustomerRequestServiceImpl">

<constructor-argname="customerRequestDao"ref="customerRequestDao"/>

<replaced-methodname="getMyBean"replacer="methodReplacer"/>

</bean>



<beanid="methodReplacer"

class="sample.spring.chapter04.bankapp.service.MyMethodReplacer"/>

The above example listing shows bean definitions for MyMethodReplacer and

CustomerRequestServiceImplclasses.The<replace-method>element’snameattributespecifiesnameof

the method that you want to override, and the replacer attribute specifies reference to the bean that

implementstheMethodReplacerinterface.Themethodspecifiedbythenameattributeisoverriddenby

thereimplementmethodofthebeanreferencedbythereplacerattribute.

As in case of <lookup-method> element, the main method of the BankApp class of ch04-bankapp-

replaced-methodproject validates whether or not the <replaced-method> element overrides the

CustomerRequestService’s getMyBean method with the MyMethodReplacer’s reimplement method.

BankAppclassofch04-bankapp-replaced-methodprojectissameastheonewesawinexamplelisting

4-18 for ch04-bankapp-lookup-methodproject. If you execute the main method of the BankApp class,

you’llfindthat<replaced-method>elementoverridesCustomerRequestServiceImpl’sgetMyBeanmethod

withMyMethodReplacer’sreimplement method; therefore, a fresh instance of CustomerRequestDetails

instanceisretrievedfromtheSpringcontainereachtimeCustomerRequestServiceImpl’ssubmitRequest

method(referexamplelisting4-19)isinvoked.

It is important to note that you can use <replaced-method> element to replace an abstract or concrete

method of a bean class with a different method implementation. For instance, we could have defined

getMyBeanmethodasanabstractmethodandusedthe<replaced-method>elementinthesamewayas

describedinthissection.

NOTEAsthebeanclassneedstobesubclassedatruntimebytheSpringcontainertoreplaceabean

methodwithadifferentmethod,theSpringcontainerusesCGLIB(http://cglib.sourceforge.net/)libraryto

performsubclassingofthebeanclass.StartingwithSpring3.2,theCGLIBclassesarepackagedwithin

thespring-coreJARfileitself;therefore,youdon’tneedtoexplicitlyspecifythatyourprojectis

dependentonCGLIBJARfile.

Let’snowlookathow<replaced-method>elementuniquelyidentifiesthebeanmethodtobeoverridden.

Uniquelyidentifyingthebeanmethod

You may come across scenarios in which the bean method that you want to replace using <replaced-

method>elementcan’tbeuniquelyidentifiedbyname.Forinstance,thefollowingexamplelistingshows

abeanclassthatcontainsoverloadedperformmethods:

Examplelisting4-22–Overloadedmethodsinabeanclass



publicclassMyBean{

publicvoidperform(Stringtask1,Stringtask2){.....}

publicvoidperform(Stringtask){.....}

publicvoidperform(my.Tasktask){.....}

}

In theabove examplelisting, theMyBean class contains multiplemethods named perform. To uniquely

identifythebeanmethodtobeoverridden,the<replaced-method>elementuses<arg-type>sub-elements

to specify method argument types. For instance, the following example listing shows how <replaced-

method>elementspecifiesthattheperform(String,String)methodofMyBeanclassshouldbereplaced:

Examplelisting4-23–<replaced-method>elementwith<arg-type>sub-element



<beanid="mybean"class="MyBean">

<replaced-methodname="perform"replacer=".....">

<arg-type>java.lang.String</arg-type>

</replaced-method>

</bean>

Insteadofusingthefully-qualifiednameasthevalueof<arg-type>element,youcanuseasubstringofthe

fully-qualifiednameasthevalue.Forinstance,insteadofusingjava.lang.String,youcanspecifyStror

Stringasthevalueof<arg-type>elementintheaboveexamplelisting.

Let’snowlookatSpring’sautowiringfeaturethatsavesyoutheeffortofspecifyingbeandependenciesin

theapplicationcontextXMLfile.

4-6Autowiringdependencies

In Spring, you have the option to either explicitly specify bean dependencies using <property> and

<constructor-arg>elementsorletSpringautomaticallyresolvebeandependencies.Theprocessinwhich

dependenciesareautomaticallyresolvedbySpringisreferredtoas‘autowiring’.

IMPORTchapter4/ch04-bankapp-autowiring(This project shows the MyBank application that uses

Spring’sautowiringfeaturefordependencyinjection.Toruntheapplication,executethemainmethodof

theBankAppclassofthisproject)

The<bean>element’sautowireattributespecifieshowabean’sdependenciesareautomaticallyresolved

by Spring. The autowire attribute can take any one of the following values: default, byName, byType,

constructorandno.Let’snowlookateachoftheseattributevaluesindetail.

NOTEYoushouldnotethatthe<bean>element’sautowireattributeisnotinheritedbychildbean

definitions.

byType

Ifyouspecifyautowireattribute’svalueasbyType,Springautowiresbeanpropertiesbasedontheirtype.

For instance, if a bean A defines a property of type X, Spring finds a bean of type X in the

ApplicationContextandinjectsitintobeanA.Let’slookatanexampleusageofbyTypeautowiringinthe

MyBankapplication.

ThefollowingexamplelistingshowstheMyBankapplication’sCustomerRegistrationServiceImplclass:

Examplelisting4-24–CustomerRegistrationServiceImplclass

Project–ch04-bankapp-autowiring

Sourcelocation-src/main/java/sample/spring/chapter04/bankapp/service



packagesample.spring.chapter04.bankapp.service;



publicclassCustomerRegistrationServiceImplimplementsCustomerRegistrationService{



privateCustomerRegistrationDetailscustomerRegistrationDetails;

privateCustomerRegistrationDaocustomerRegistrationDao;

....

publicvoidsetCustomerRegistrationDetails(

CustomerRegistrationDetailscustomerRegistrationDetails){

this.customerRegistrationDetails=customerRegistrationDetails;

}

publicvoidsetCustomerRegistrationDao(

CustomerRegistrationDaocustomerRegistrationDao){

this.customerRegistrationDao=customerRegistrationDao;

}

.....

}

The above example listing shows that the CustomerRegistrationServiceImpl class defines properties

namedcustomerRegistrationDetails(oftypeCustomerRegistrationDetails)andcustomerRegistrationDao

(of type CustomerRegistrationDao). This means that the CustomerRegistrationDetails and

CustomerRegistrationDaoobjectsaredependenciesofCustomerRegistrationServiceImplobject.

The following example listing shows bean definitions for CustomerRegistrationServiceImpl,

CustomerRegistrationDetails and CustomerRegistrationDaoImpl (an implementation of

CustomerRegistrationDaointerface)classes:

Examplelisting4-25–applicationContext.xml-autowiringbyTypeconfiguration

Project–ch04-bankapp-autowiring

Sourcelocation-src/main/resources/META-INF/spring

<beanid="customerRegistrationService"

class="sample.spring.chapter04.bankapp.service.CustomerRegistrationServiceImpl"

scope="prototype"autowire="byType"/>



<beanid="customerRegistrationDetails"

class="sample.spring.chapter04.bankapp.domain.CustomerRegistrationDetails"

scope="prototype"/>



<beanid="customerRegistrationDao"

class="sample.spring.chapter04.bankapp.dao.CustomerRegistrationDaoImpl"/>

Intheaboveexamplelisting,thecustomerRegistrationServicebeandefinitiondoesn’tcontain<property>

elementsforsettingcustomerRegistrationDetailsandcustomerRegistrationDaoproperties(referexample

listing4-24).Instead,the<bean>elementspecifiesautowireattribute’svalueasbyTypetoinstructSpring

to automatically resolve dependencies of the customerRegistrationService bean based on their type.

Spring looks for beans of types CustomerRequestDetails and CustomerRegistrationDao in the

ApplicationContext, and injects them into the customerRegistrationService bean. As

customerRegistrationDetails and customerRegistrationDao beans represent beans of types

CustomerRegistrationDetails and CustomerRegistrationDao, the Spring container injects

customerRegistrationDetailsandcustomerRegistrationDaobeansintocustomerRegistrationServicebean.

It may happen that Spring doesn’t find any bean registered with the ApplicationContext whose type

matches the property type. In such cases, no exception is thrown and the bean property is not set. For

instance, if a bean defines a property x of type Y, and there is no bean of type Y registered with the

ApplicationContext instance, the property x is not set. If Spring finds multiple beans in the

ApplicationContextthatmatchthepropertytype,anexceptionisthrown.Insuchcases,insteadofusing

autowiringfeature,use<property>elementstoexplicitlyidentifybeandependenciesorsetabeanasthe

primarycandidateforautowiringbysettingthevalueofprimaryattributeof<bean>elementtotrue.

constructor

If you specify autowire attribute’s value as constructor, Spring autowires bean class’s constructor

argumentsbasedontheirtype.Forinstance,ifbeanA’sconstructoracceptsargumentsoftypeXandY,

SpringfindsbeansoftypesXandYintheApplicationContextandinjectsthemasargumentstobeanA’s

constructor.Let’slookatanexampleusageofconstructorautowiringintheMyBankapplication.

ThefollowingexamplelistingshowstheMyBankapplication’sCustomerRequestServiceImplclass:

Examplelisting4-26–CustomerRequestServiceImplclass

Project–ch04-bankapp-autowiring

Sourcelocation-src/main/java/sample/spring/chapter04/bankapp/service



packagesample.spring.chapter04.bankapp.service;



publicclassCustomerRequestServiceImplimplementsCustomerRequestService{

privateCustomerRequestDetailscustomerRequestDetails;

privateCustomerRequestDaocustomerRequestDao;



@ConstructorProperties({"customerRequestDetails","customerRequestDao"})

publicCustomerRequestServiceImpl(

CustomerRequestDetailscustomerRequestDetails,

CustomerRequestDaocustomerRequestDao){

this.customerRequestDetails=customerRequestDetails;

this.customerRequestDao=customerRequestDao;

}

.....

}

The CustomerRequestServiceImpl class defines a constructor that accepts arguments of type

CustomerRequestDetailsandCustomerRequestDao.

The following example listing shows bean definitions for CustomerRequestServiceImpl,

CustomerRequestDetails and CustomerRequestDaoImpl (an implementation of CustomerRequestDao

interface)classes:

Examplelisting4-27–applicationContext.xml-constructorautowiring

Project–ch04-bankapp-autowiring

Sourcelocation-src/main/resources/META-INF/spring

<beanid="customerRequestService"

class="sample.spring.chapter04.bankapp.service.CustomerRequestServiceImpl"

autowire="constructor">

</bean>



<beanid="customerRequestDetails"

class="sample.spring.chapter04.bankapp.domain.CustomerRequestDetails"scope="prototype"/>



<beanid="customerRequestDao"

class="sample.spring.chapter04.bankapp.dao.CustomerRequestDaoImpl"/>

In theaboveexamplelisting,thecustomerRequestServicebeandefinitionspecifiesautowire attribute’s

value as constructor, which means that Spring locates beans of types CustomerRequestDetails and

CustomerRequestDao in the ApplicationContext, and passes them as arguments to

CustomerRequestServiceImpl class’s constructor. As customerRequestDetails and customerRequestDao

beans are of type CustomerRequestDetails and CustomerRequestDao, Spring automatically injects

instancesofthesebeansintocustomerRequestServicebean.

IfSpringdoesn’tfindanybeanintheApplicationContextwhosetypematchestheconstructorargument

type, the constructor argument is not set. If Spring finds multiple beans in the ApplicationContext that

match the constructor argument type, an exception is thrown; therefore, in such scenarios use

<constructor-arg> elements to explicitly identify bean dependencies or set a bean as the primary

candidateforautowiringbysettingvalueofprimaryattributeof<bean>elementtotrue.

byName

If you specify autowire attribute’s value as byName, Spring autowires bean properties based on their

names. For instance, if a bean A defines a property named x, Spring finds a bean named x in the

ApplicationContextandinjectsitintobeanA.Let’slookatanexampleusageofbyNameautowiringinthe

MyBankapplication.

ThefollowingexamplelistingshowstheMyBankapplication’sFixedDepositServiceImplclass:

Examplelisting4-28–FixedDepositServiceImplclass

Project–ch04-bankapp-autowiring

Sourcelocation-src/main/java/sample/spring/chapter04/bankapp/service



packagesample.spring.chapter04.bankapp.service;



importsample.spring.chapter04.bankapp.dao.FixedDepositDao;

importsample.spring.chapter04.bankapp.domain.FixedDepositDetails;



publicclassFixedDepositServiceImplimplementsFixedDepositService{

privateFixedDepositDaomyFixedDepositDao;



publicvoidsetMyFixedDepositDao(FixedDepositDaomyFixedDepositDao){

this.myFixedDepositDao=myFixedDepositDao;

}

.....

}

The above example listing shows that FixedDepositServiceImpl class defines a property named

myFixedDepositDaooftypeFixedDepositDao.

The following example listing shows bean definitions for FixedDepositServiceImpl and

FixedDepositDaoImpl(animplementationofFixedDepositDaointerface)classes:

Examplelisting4-29–applicationContext.xml-byNameautowiring

Project–ch04-bankapp-autowiring

Sourcelocation-src/main/resources/META-INF/spring

<beanid="FixedDepositService"

class="sample.spring.chapter04.bankapp.service.FixedDepositServiceImpl"

autowire="byName"/>



<beanid="myFixedDepositDao"

class="sample.spring.chapter04.bankapp.dao.FixedDepositDaoImpl"/>

Intheaboveexamplelisting,FixedDepositServicebeandefinitionspecifiesautowireattribute’svalueas

byName, which means properties of FixedDepositService bean are automatically resolved by Spring

basedontheirnames.Inlisting4-28,wesawthattheFixedDepositServiceImplclassdefinesaproperty

named myFixedDepositDao; therefore, Spring looks for a bean named myFixedDepositDao in the

ApplicationContext and injects it into FixedDepositService bean. In the above example listing,

myFixedDepositDao bean definition represents the FixedDepositDaoImpl class, which means that an

instance of FixedDepositDaoImpl is injected for property named myFixedDepositDao in the

FixedDepositServicebean.

default/no

Ifyouspecifyautowireattribute’svalueasdefaultorno,autowiringfeatureisdisabledforthebean.As

Spring’s default behavior is to use no autowiring for beans, specifying autowire attribute’s value as

defaultmeansnoautowiringwillbeperformedforthebean.Youcanexplicitlyspecifythatabeanmust

notuseSpring’sautowiringfeaturebyspecifyingautowireattribute’svalueasno.

NOTEYoucanchangethedefaultautowiringbehaviorofbeansbysettingthedefault-autowireattribute

of<beans>element.For instance, if you set default-autowire attribute’s value tobyType, it effectively

meanssettingvalueofautowireattributeofallthe<bean>elementsintheapplicationcontextXMLfileto

byType.Youshouldnotethatifa<bean>element’sautowireattributespecifiesadifferentvaluethanthe

<beans>element’sdefault-autowireattribute,the<bean>element’sautowireattributevalueappliestothe

bean.

The following example listing shows the bean definition for the MyBank application’s

CustomerRegistrationServiceImplclassthatspecifiesautowireattribute’svalueasno:

Examplelisting4-30–applicationContext.xml-noautowiring

Project–ch04-bankapp-autowiring

Sourcelocation-src/main/resources/META-INF/spring

<beanid="customerRegistrationService_"

class="sample.spring.chapter04.bankapp.service.CustomerRegistrationServiceImpl"

scope="prototype"autowire="no"/>

Example listing 4-24 showed that the CustomerRegistrationServiceImpl class defines

customerRegistrationDetails(oftypeCustomerRegistrationDetails)andcustomerRegistrationDao(oftype

CustomerRegistrationDao) properties. As the autowire attribute’s value is specified as no for

customerRegistrationService_bean,autowiringisdisabledforcustomerRegistrationService_bean.This

means that the customerRegistrationDetails and customerRegistrationDao properties of

customerRegistrationService_beanarenotsetbySpring.

So far in this section we have seen different ways in which bean dependencies can be autowired by

Spring.Let’snowlookathowwecanmakeabeanunavailableforautowiringpurposesusing<bean>

element’sautowire-candidateattribute.

Makingbeansunavailableforautowiring

ThedefaultbehavioroftheSpringcontaineristomakebeansavailableforautowiring.Youcanmakea

beanunavailabletootherbeansforautowiringpurposesbysettingautowire-candidateattribute’svalueto

false.

In MyBank application, the AccountStatementServiceImpl class defines a property of type

AccountStatementDao.ThefollowingexamplelistingshowstheAccountStatementServiceImplclass:

Examplelisting4-31–AccountStatementServiceImplclass

Project–ch04-bankapp-autowiring

Sourcelocation-src/main/java/sample/spring/chapter04/bankapp/service



packagesample.spring.chapter04.bankapp.service;



importsample.spring.chapter04.bankapp.dao.AccountStatementDao;

importsample.spring.chapter04.bankapp.domain.AccountStatement;



publicclassAccountStatementServiceImplimplementsAccountStatementService{

privateAccountStatementDaoaccountStatementDao;



publicvoidsetAccountStatementDao(AccountStatementDaoaccountStatementDao){

this.accountStatementDao=accountStatementDao;

}

.....

}

The following example listing shows bean definitions for AccountStatementServiceImpl and

AccountStatementDaoImpl(animplementationofAccountStatementDaointerface)classes:

Examplelisting4-32–applicationContext.xml-autowire-candidateattribute

Project–ch04-bankapp-autowiring

Sourcelocation-src/main/resources/META-INF/spring

<beanid="accountStatementService"

class="sample.spring.chapter04.bankapp.service.AccountStatementServiceImpl"

autowire="byType"/>



<beanid="accountStatementDao"

class="sample.spring.chapter04.bankapp.dao.AccountStatementDaoImpl"

autowire-candidate="false"/>

Intheaboveexamplelisting,theaccountStatementServicebeandefinitionspecifiesautowireattribute’s

valueas byType, which means AccountStatementDaopropertytype ofaccountStatementService bean is

autowiredbytype.AsaccountStatementDaobeanisoftypeAccountStatementDao,you mightthink that

Spring will inject accountStatementDao bean instance into accountStatementService bean. But, Spring

won’t consider accountStatementDao bean for autowiring purposes because the accountStatementDao

beandefinitionspecifiesautowire-candidateattribute’svalueasfalse.

NOTEYoushouldnotethatabeanthatisunavailabletootherbeansforautowiringpurposescanitself

makeuseofSpring’sautowiringfeaturetoautomaticallyresolveit’sdependencies.

As mentioned earlier, the default behavior of the Spring container is to make beans available for

autowiring purposes. To make only only a select set of beans available for autowiring purposes, set

<beans> element’s default-autowire-candidates attribute. The default-autowire-candidates attribute

specifies a bean name pattern, and only beans whose names match the specified pattern are made

available for autowiring. The followingexamplelisting shows anexample usageof default-autowire-

candidatesattribute:

Examplelisting4-33–default-autowire-candidatesattributeexample

<beansdefault-autowire-candidates="*Dao">

.....

<beanid="customerRequestDetails"

class="sample.spring.chapter04.bankapp.domain.CustomerRequestDetails"

scope="prototype"autowire-candidate="true"/>



<beanid="customerRequestDao"

class="sample.spring.chapter04.bankapp.dao.CustomerRequestDaoImpl"/>



<beanid="customerRegistrationDao"

class="sample.spring.chapter04.bankapp.dao.CustomerRegistrationDaoImpl"/>

.....

</beans>

Intheaboveexamplelisting,default-autowire-candidatesvalueissetto*Dao,whichmeansthatbeans

whose names end with Dao (like customerRequestDao and customerRegistrationDao beans) will be

available for autowiring purposes. If a bean name doesn’t match the pattern specified by the default-

autowire-candidates attribute (like customerRequestDetails bean), you can still make it available for

autowiringpurposesbysettingtheautowire-candidateattributeofthecorresponding<bean>elementto

true.

Let’snowlookatlimitationsofusingautowiringinapplications.

Autowiringlimitations

Wesawthatautowiringfeaturesavestheefforttoexplicitlyspecifybeandependenciesusing<property>

and<constructor-arg>elements.Thedownsidesofusingautowiringfeatureare:

·Youcan’tuseautowiringtosetpropertiesorconstructorargumentsthatareofsimpleJavatypes

(likeint,long,boolean,String,Date, and so on). You canautowire arrays, typed collections and

mapsiftheautowireattribute’svalueissettobyTypeorconstructor.

·        As bean dependencies are automatically resolved by Spring, it results in hiding the overall

structureoftheapplication.Ifyouuse<property>and<constructor-arg>elementstospecifybean

dependencies,itresultsinexplicitlydocumentingtheoverallstructureoftheapplication.Youcan

easily understand and maintain an application in which bean dependencies are explicitly

documented.Forthisreason,itisnotrecommendedtouseautowiringinlargeapplications.

4-7Summary

Inthischapter,welookedathowSpringcaterstodifferentdependencyinjectionscenarios.Welookedat

how you can use ApplicationContextAware interface, <replaced-method> and <lookup-method> sub-

elementsof<bean> element toprogrammaticallyretrieve abean instance from the ApplicationContext.

We also looked at how Spring’s autowiring feature can save the effort for explicitly specifying bean

dependencies in the application context XML file. In the next chapter, we’ll look at how to customize

beansandbeandefinitions.

Chapter5-Customizingbeansandbeandefinitions

5-1Introduction

SofarinthisbookwehaveseenexamplesinwhichtheSpringcontainercreatedabeaninstancebasedon

thebeandefinitionspecifiedintheapplicationcontextXMLfile.Inthischapter,we’llgoastepfurther

andlookat:

·howtoincorporatecustominitializationanddestructionlogicforabean

·howtointeractwithanewlycreatedbeaninstancebyimplementingSpring’sBeanPostProcessor

interface

·howtomodifybeandefinitionsbyimplementingSpring’sBeanFactoryPostProcessorinterface

5-2Customizingbean’sinitializationanddestructionlogic

We saw in earlier chapters that the Spring container is responsible for creating a bean instance and

injectingitsdependencies.Aftercreatingabeaninstancebyinvokingtheconstructorofthebeanclass,the

Springcontainersetsbeanpropertiesbyinvokingbean’ssettermethods.Ifyouwanttoexecutecustom

initialization logic (like opening a file, creating a database connection, and so on) after the bean

propertiesaresetbutbeforethebeaniscompletelyinitializedbytheSpringcontainer,youcandosoby

specifyingthenameoftheinitializationmethodasthevalueofinit-methodattributeof<bean>element.

Similarly,ifyou wantto executecustomcleanuplogic before the Spring container containingthe bean

instance is destroyed, you can specify the name of the cleanup method as the value of destroy-

methodattributeof<bean>element.

IMPORT chapter 5/ch05-bankapp-customization (This project shows the MyBank application that

uses <bean> element’s init-method and destroy-method elements to specify custom initialization and

destructionmethods.Totestwhethertheinitializationmethodisexecuted,executethemainmethodofthe

BankApp class of this project. To test whether the destruction method is executed, execute the main

methodoftheBankAppWithHookclassofthisproject.)

The following example listing shows the MyBank’s FixedDepositDaoImpl class that defines an

initializationmethodnamedinitializeDbConnectionforobtainingconnectiontoMyBank’sdatabase,anda

destructionmethodnamedreleaseDbConnectionforreleasingtheconnection:

Examplelisting5-1–FixedDepositDaoImplclass-Custominitializationanddestructionlogic

Project–ch05-bankapp-customization

Sourcelocation-src/main/java/sample/spring/chapter05/bankapp/dao



packagesample.spring.chapter05.bankapp.dao;



publicclassFixedDepositDaoImplimplementsFixedDepositDao{

privatestaticLoggerlogger=Logger.getLogger(FixedDepositDaoImpl.class);

privateDatabaseConnectionconnection;



publicFixedDepositDaoImpl(){

logger.info("FixedDepositDaoImpl'sconstructorinvoked");

}



publicvoidinitializeDbConnection(){

logger.info("FixedDepositDaoImpl’sinitializeDbConnectionmethodinvoked");

connection=DatabaseConnection.getInstance();

}



publicbooleancreateFixedDeposit(FixedDepositDetailsfixedDepositDetails){

logger.info("FixedDepositDaoImpl’screateFixedDepositmethodinvoked");

//--savethefixeddepositsandthenreturntrue

returntrue;

}



publicvoidreleaseDbConnection(){

logger.info("FixedDepositDaoImpl’sreleaseDbConnectionmethodinvoked");

connection.releaseConnection();

}

}

In the above example listing, the DatabaseConnection object is used for interacting with the MyBank’s

database. FixedDepositDaoImpl class defines an initializeDbConnection method that initializes the

DatabaseConnection object, which is later used by the createFixedDeposit method for saving fixed

depositdetailsintheMyBank’sdatabase.

The following example listing shows the MyBank’s FixedDepositServiceImpl class that uses

FixedDepositDaoImplinstancetocreatenewfixeddeposits:

Examplelisting5-2–FixedDepositServiceImplclass

Project–ch05-bankapp-customization

Sourcelocation-src/main/java/sample/spring/chapter05/bankapp/service



packagesample.spring.chapter05.bankapp.service;



publicclassFixedDepositServiceImplimplementsFixedDepositService{

privatestaticLoggerlogger=Logger.getLogger(FixedDepositServiceImpl.class);

privateFixedDepositDaomyFixedDepositDao;



publicvoidsetMyFixedDepositDao(FixedDepositDaomyFixedDepositDao){

logger.info("FixedDepositServiceImpl'ssetMyFixedDepositDaomethodinvoked");

this.myFixedDepositDao=myFixedDepositDao;

}



@Override

publicvoidcreateFixedDeposit(FixedDepositDetailsfixedDepositDetails)throwsException{

//--createfixeddeposit

myFixedDepositDao.createFixedDeposit(fixedDepositDetails);

}

}

The above example listing shows that the FixedDepositDaoImpl instance is a dependency of

FixedDepositServiceImpl, and is passed as an argument to the setMyFixedDepositDao setter-method.

And, if FixedDepositServiceImpl’s createFixedDeposit method is invoked, it results in invocation of

FixedDepositDaoImpl’screateFixedDepositmethod.

The following example listing shows bean definitions for FixedDepositDaoImpl and

FixedDepositServiceImplclasses:

Examplelisting5-3–applicationContext.xml–usageofinit-methodanddestroy-methodattributes

Project–ch05-bankapp-customization

Sourcelocation-src/main/resources/META-INF/spring



<beans.....>

<beanid="FixedDepositService"

class="sample.spring.chapter05.bankapp.service.FixedDepositServiceImpl">

<propertyname="myFixedDepositDao"ref="myFixedDepositDao"/>

</bean>



<beanid="myFixedDepositDao"

class="sample.spring.chapter05.bankapp.dao.FixedDepositDaoImpl"

init-method="initializeDbConnection"destroy-method="releaseDbConnection"/>

</beans>

The above example listing shows that the <bean> element corresponding to the FixedDepositDaoImpl

class specifies initializeDbConnection and releaseDbConnection as the values of init-method and

destroy-methodattributes,respectively.

NOTEItisimportanttonotethattheinitializationanddestructionmethodsspecifiedbytheinit-method

anddestroy-methodattributesof<bean>elementmustnotacceptanyarguments,butcanbedefinedto

throwexceptions.

The following example listing shows BankApp class whose main method retrieves

FixedDepositServiceImplinstancefromtheApplicationContextandinvokesFixedDepositServiceImpl’s

createFixedDepositmethod:

Examplelisting5-4–BankAppclass

Project–ch05-bankapp-customization

Sourcelocation-src/main/java/sample/spring/chapter05/bankapp



packagesample.spring.chapter05.bankapp;



publicclassBankApp{

publicstaticvoidmain(Stringargs[])throwsException{

ApplicationContextcontext=newClassPathXmlApplicationContext(

"classpath:META-INF/spring/applicationContext.xml");



FixedDepositServiceFixedDepositService=context.getBean(FixedDepositService.class);

FixedDepositService.createFixedDeposit(newFixedDepositDetails(1,1000,

12,"someemail@somedomain.com"));

}

}

IfyounowexecutetheBankApp’smainmethod,you’llseethefollowingoutputontheconsole:

FixedDepositDaoImpl'sconstructorinvoked

FixedDepositDaoImpl’sinitializeDbConnectionmethodinvoked

FixedDepositServiceImpl'ssetMyFixedDepositDaomethodinvoked

FixedDepositDaoImpl’screateFixedDepositmethodinvoked

TheaboveoutputshowsthattheSpringcontainerfirstcreatesFixedDepositDaoImpl’sinstance,andthen

invokes initializeDbConnection method. After the invocation of initializeDbConnection method, the

FixedDepositDaoImplinstanceisinjectedintotheFixedDepositServiceImplinstance.Thisshowsthatthe

Springcontainerinjectsadependency(theFixedDepositDaoImplinstance)intothedependentbean(the

FixedDepositServiceImpl instance) after the initialization method of the dependency is invoked by the

Springcontainer.

YoumayhavenoticedthattheoutputfromexecutingBankApp’smainmethoddidn’tcontainthefollowing

message:FixedDepositDaoImpl’sreleaseDbConnectionmethodinvoked(referFixedDepositDaoImpl’s

releaseDbConnection method in example listing 5-1). This means that the FixedDepositDaoImpl’s

releaseDbConnection method was not called by the Spring container when BankApp’s main method

exited.Inarealworldapplicationdevelopmentscenario,thismeansthatthedatabaseconnectionheldby

FixedDepositDaoImpl instance is never released. Let’s now see how you can make Spring gracefully

destroysingleton-scopedbeaninstancesbycallingthecleanupmethodspecifiedbythe<bean>element’s

destroy-methodattribute.

MakingSpringinvokecleanupmethodspecifiedbythedestory-methodattribute

The web version of ApplicationContext implementation is represented by Spring’s

WebApplicationContextobject.WebApplicationContextimplementationhasthenecessarylogictoinvoke

thecleanupmethod(specifiedbythedestroy-methodattribute)ofsingleton-scopedbeaninstancesbefore

thewebapplicationisshutdown.

NOTETheapproachdescribedinthissectiononmakingSpringgracefullydestroysingleton-scopedbean

instancesbycallingthecleanupmethodisspecifictostandaloneapplications.

Thefollowingexa