———————————————————————————————-
Chapter 1: Spring into action:
———————————————————————————————-

1.1 What is Spring ?:
- Spring is a lightweight dependency injection and aspect-oriented container
and framework.
- Main features of Spring:
- Lightweight:
- Spring is lightweight in terms of both size and overhead.
- Objects in a Spring-enabled application often have no
dependencies on Spring-specific classes.
- Dependency Injection:
- Spring promotes loose coupling through a technique known
as dependency injection (DI). objects are passively given
their dependencies instead of creating or looking for
dependent objects for themselves.
- Aspect-oriented:
- Enables cohesive development by separating application
business logic from system services, so the application
objects will do what they are supposed to do -perform
business logic- and nothing more.
- Container:
- Spring is a container in the sense that it contains and
manages the lifecycle and configuration of application
objects.
- In Spring, you declare how each of your application objects
should be create, how they should be configured, and how
they should be configured, and how they should be associated
with each other.
- Framework:
- Spring makes it possible to configure and compose complex applications
from simpler components.

- Spring helps you develop loosely coupled application code,
so (maintainability and testability).

1.1.1 Spring modules:
- The Spring Framework is composed of several well-defined modules built
on top of the core container.
- Spring offers integration points with several other frameworks and libraries
so you won’t have to write them yourself.

* The core container:
- provides the fundamental functionality of the spring framework.
- This module contains the BeanFactory which is the basis on which
Spring’s DI is based.
* Application context module:
- This module makes Spring a framework by adding support for
internationalization messages, application lifecycle events, and
validation.
* Spring’s AOP module:
- Supports loose coupling of application objects.
- Applicationwide concerns (such as transactions and security)
are decoupled from the objects to which they are applied.
* JDBC abstraction and the DAO module:
- Abstracts a way the boilerplate code so that you can keep your database code
clean and simple.
- Uses Spring’s AOP module to provide transaction management services for
objects in a Spring application.
* Object-relational mapping (ORM) integration module:
- Provides adapter for popular ORM frameworks, including Hibernate, JPA, JDO,
and iBATIS SQL Maps.
* Java Management Extensions (JMX):
- Makes it easy to expose your application’s beans as JMX MBeans.
* Java EE Connector API (JCA):
- Abstracting away JCA’s boilerplate code into templates.
* The Spring MVC framework:
- Spring comes with its own very capable MVC framework that promotes Spring’s
loosely coupled techniques in the web layer of an application.
- integrates with several popular MVC frameworks.
* Spring Portlet MVC:
- Builds on Spring MVC to provide a set of controllers that
support Java’s portlet API.
* Spring’s web module:
- provides special support classes for Spring MVC and Spring Portlet MVC.
- Supports several web-oriented tasks, such as multipart file uploads and
programmatic binding of request parameters to you business objects.
- Integration support with Apache Struts and Java Server Faces (JSF).
* Remoting:
- Support enabling to expose the functionality of your java objects as
remote objects, using many options, RMI, Hessian, Burlap, JAX-RPC, and
Spring’s own HTTP Invoker.
* Java Message Service (JMS):
- Helps you send messages to JMS message queues and topics.

1.2 A Spring jump start:
Listing 1.1: The interface for a greeting service:
package com.springinaction.chapter01.hellp;
public interface GreetingService {
void sayGreeting();
}
Listing 1.2: GreetingServiceImpl, which prints a friendly greeting:
package com.springinaction.chapter01.hello;
public class GreetingServiceImpl implements GreetingService {
private String greeting;
public GreetingServiceImpl() {}
public GreetingServiceImpl(String greeting) {
this.greeting = greeting;
}
public void sayGreeting() {
System.out.println(greeting);
}
public void setGreeting(String greeting){
this.greeting = greeting;
}
}

- note that it is not apparent yet who will make the call to either the
constructor or the setGreeting() method to set the property.
- the Spring configuration file (hello.xml) tell the container how to configure
the greeting service:
Listing 1.3: configuring Hello world in Spring:
<?xml version=”1.0″ encoding=”UTF-8″ ?>
<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-2.0.xsd”
>
<bean id=”greetingService”>
<property name=”greeting” value=”Welcome to First application using Spring” />
</bean>
</beans>
=====>
GreetingServiceImpl greetingService = new GreetingServiceImpl();
greetingService.setGreeting(“Welcome to First application using Spring”);
======
or
<bean id=”greetingService”>
<constructor-arg value=”Welcome to First application using Spring” />
</bean>
======>
GreetingServiceImpl greetingService =
new GreetingServiceImpl(“Welcome to First application using Spring”);
=======

- The class that loads the Spring container and uses it to retrieve the greeting service:
Listing 1.4: The Hello World main class:
package com.springinaction.chapter01.hello;
import org.springframework.beans.factory.BeanFactory;
import org.springFramework.beans.factory.xml.XmlBeanFactory;
import org.springframework.core.io.FileSystemResource;

public class HelloApp {
public static void main(String[] args) throws Exception {
BeanFactory factory =
new XmlBeanFactory(new FileSystemResource(“hello.xml”));
GreetingService greetingService =
(GreetingService) factory.getBean(“greetingService”);
greetingService.sayGreeting();
}
}

- The BeanFactory class used here is the Spring container.
- This example is too simple because it only illustrates how to configure a bean
by injecting a String value into a property.
the real power of Spring lies in how beans can be injected into other beans using DI.

1.3: Understanding dependency injection:
- DI is at the heart of the Spring Framework.
- by applying DI in your projects, you’ll find that your code will become significantly
simpler, easier to understand, and easier to test.

1.3.1: injecting dependencies:
- Dependency injection involves giving an object its dependencies as opposed to an
object having to acquire those dependencies on its own.
- The key benefit of DI is loose coupling. if an object only knows about its dependencies
by their interface (not their implementation or how they were instantiated) then the
dependency can be swapped out with a different implementation without the depending object
knowing the difference.
- by doing this the injected object can be a local POJO, a remote web service, and EJB.

1.3.2: Dependency injection in action:
- Classes need to know about each other somehow. So coupling is necessary, but
it should be managed carefully.
- A common technique used to reduce coupling is to hide implementation details behind
interfaces so that the actual implementation class can be swapped out without impacting
the client class.
- The DI is all about: the responsibility of coordinating collaboration between dependent objects
is transferred away from the objects themselves.
- The act of creating associations between application components is referred to as wiring.
In Spring there are many ways to wire components together, but the most common approach is
via XML.
- EX:
<bean id=”quest”/>
<bean id=”knight”>
<constructor-arg value=”Bedivere” />
<property name=”quest” ref=”quest”/>
</bean>

- In a Spring application, a BeanFactory loads the bean definitions and wires the beans
together. and because it is declared in an XML file, an XmlBeanFactory is the appropriate
factory.

1.3.3: Dependency injection in enterprise applications:
- You might choose to hide the lookup details behind a service locator.
this would address the coupling concerns seen with the other approaches, but
now the web layer is coupled to the service locator.
- the key issue with all of these approaches is that the web layer component is too
involved in obtaining its own dependencies. it knows too much about where the order
service comes from and how it’s implemented.
- if knowing too much about your dependencies leads to tightly coupled code, it
stands to reason that knowing as little as possible about your dependencies leads
to loosely coupled code.

1.4: Applying aspect-oriented programming:
- Enables you to capture functionality that is used throughout your application in
reusable components.
- promotes separation of concerns within a software system.
- in short, aspects ensure that POJOs remain plain.
- it keeps the security, transaction, and loggin concerns from littering the
application’s core business logic.

1.4.2: AOP in action:
* Weaving the aspect:
- first add the following namespace to already declared xml file:
<beans … http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.0.xsd”>

<bean id=”minstrel”/>
<aop:config>
<aop:aspect ref=”minstrel”>
<aop:pointcut id=”questPointcut”
expression=”execution(* *.emarkOnQuest(..)) and target(bean)” />
<aop:before
method=”singBefore”
pointcut-ref=”questPointcut”
arg-names=”bean” />
<aop:after-returning
method=”singAfter”
pointcut-ref=”questPointcut”
arg-names=”bean” />
</aop:aspect>
</aop:config>
…
</beans>

- The minstrel bean, which is a Minstrel, will provide the functionality of the aspect.
- point-cut defines a pointcut that is triggered by the execution of an embarkOnQuest()
method.
- Then there are an advice. or how to apply the functionality.

1.5: Summary:
- Spring aims to make enterprise Java development easier and to promote loosely coupled code.
by using DI and AOP.
- AOP enables you to centralize logic that would normally be scattered throughout an application
in one place – an aspect. When Spring wires your beans together, these aspects can be woven
in at runtime, effectively giving the beans new behavior.

———————————————————————————————-
Chapter 2: Basic bean wiring:
———————————————————————————————-

- objects are not responsible for finding or creating the other objects that they need to do
their job. Instead, they are given references to the objects that they collaborate with by
the container.
- The act of creating these associations between application objects is the essence of
dependency injection (DI) and is commonly referred to as wiring.

2.1: Containing your beans:
- In a Spring application, objects are created, wired together, and live within the Spring container.
- Spring comes with several container implementations that can be categorized into two distinct types,
Bean factories (defined by the org.springframework.beans.factory.BeanFactory interface)
are the simplest of containers, providing basic support for DI.
Application contexts (defined by the org.springframework.context.ApplicationContext interface)
providing application framework services, such as the ability to resolve textual messages from
properties file and the ability to publish application events to interested event listeners.

2.1.1: Introducing the BeanFactory:
- Most implementation of BeanFactory is org.springframework.beans.factory.xml.XmlBeanFactory;
which loads its beans based on the definitions contained in an XML file.
- To create an XmlBeanFactory, you must pass an instance of
org.springframework.core.io.Resource to the constructor. There are several Resource implementations
of this interface.
- EX.
BeanFactory factory = new XmlBeanFactory(new FileSystemResource(“c:/beans.xml”));
this tells the bean factory to read the bean definitions from the XML file.
but the bean factory doesn’t instantiate the beans just yet.
the beans themselves will not be instantiated until they are needed.
- To retrieve a bean from a BeanFactory, simply call the getBean() method, passing the ID
of the bean you want to retrieve:
MyBean myBean = (MyBean) factory.getBean(“myBean”);
when getBean() is called, the factory will instantiate the bean and set the bean’s properties
using DI. Thus begins the life of a bean within the Spring container.

2.1.2: Working with an application context:
- To gain the full power of the Spring Framework.
- An ApplicationContext is much the same as a BeanFactory. Both load bean definitions, wire beans
together, and dispense beans upon request. But an ApplicationContext offers much more:
- provides a means for resolving text messages.
- provides a generic way to load file resources, such as images.
- can publish events to beans that are registered as listeners.
- An ApplicationContext is preferred over a BeanFactory in nearly all applications.
- Among the many implementations of ApplicationContext are three that are commonly
used:
- ClassPathXmlApplicationContext:
- loads a context definition from an XML file located in the classpath.
- treating context definition files as classpath resources.
- FileSystemXmlApplicationContext:
- loads a context definition from an XML file in the file system.
- XmlWebApplicationContext:
- loads context definitions from an XML file contained within a web application.
- EX.
ApplicationContext context =
new FileSystemXmlApplicationContext(“c:/foo.xml”); // will look for foo.xml in a specific
// location within the file system.

or from within the application’s classpath using:
ApplicationContext context =
new ClassPathXmlApplicationContext(“foo.xml”); // will look for foo.xml anywhere in the
// classpath (including JAR files).

- and then you can use the getBean() method to retrieve a bean.
- The ApplicationContext interface extends the BeanFactory interface.
- The big difference between an application context and a bean factory is how singleton beans
are loaded. A bean factory lazily loads all beans, deferring bean creation until the getBean()
method is called. An application context is a bit smarter and preloads all singleton beans upon
context startup. By preloading singleton beans, you ensure that they will be ready to use when
needed – your application won’t have to wait for them to be created.

2.1.3: A bean’s life:
- A bean goes through several steps between creating and destruction in the Spring container,
each step is an opportunity to customize how the bean is managed in Spring, The steps taken
in the life of a bean are:
1- Instantiate                : Spring instantiates the bean.
2- Populate properties            : Spring injects the bean’s properties.
3- Set Bean name            : if the bean implements BeanNameAware, Spring
passes the bean’s ID to setBeanName().
4- Set bean factory            : if the bean implements BeanFactoryAware, Spring
passes the bean factory to setBeanFactory().
5- Postprocess (Before initialization)    : if there are any BeanPostProcessors, Spring
calls their postProcessBeforeInitialization()
method.
6- Initialize beans            : if the bean implements InitializingBean, its
afterPropertiesSet() method will be called.
if the bean has a custom init method declared, the
specified initialization method will be called.
7- PostProcess (After initialization)    : if there are any BeanPostprocessors, Spring calls
their postProcessAfterInitialization() method.
8- Bean is ready to use            : At this point the bean is ready to be used by
the application and will remain in the bean factory
untill it is no longer needed.
9- Destroy bean                         : if the bean implements DisposableBean, its
destroy() method will be called.
if the bean has a custom destory-method
declared, the specified method will be called.

- The lifecycle of a bean in a Spring application context extends the lifecycle of
a factory-contained bean by adding a step to make the bean application context aware.
so after step 4 above there are a step:
- ApplicationContextAware’s setApplicationContext(): if the bean implements
the ApplicationContextAware interface, the setApplicationContext() method is called.

2.2: Creating beans:

2.2.1: Declaring a simple bean:
- Declared a bean in the Spring configuration file:
<bean id=”duke” />
it equals to:
new com.springinaction.springidol.Juggler();

2.2.2: Injecting through constructors:
- Ceclared a bean with constructor:
<bean id=”duke”>
<constructor-arg value=”15″ />
</bean>

- Injecting object references with constructors:
<bean id=”sonnet29″ />
<bean id=”duke”>
<constructor-arg value=”15″ />
<constructor-arg ref=”sonnet29″ />
</bean>

same as:
Poem sonnet29 = new Sonnet29();
Performer duke = new PoeticJuggler(15, sonnet29);

* Constructor or setter injection: how do you choose ?
- The constructor-injection side:
- Constructor injection enforces a strong dependency contract. a bean cannot be
instantiated without being given all of its dependencies.
- Because all of the bean’s depenencies are set through its constructor, there’s no
need for superfluous setter methods. This helps keep the lines of code at a minimum.
- By only allowing properties to be set through the constructor, you are, effectively,
making those properties immutable, preventing accidental change in the course of
application flow.
- The setter injection side:
- if a bean has several dependencies, the constructor’s parameter list can be
quite lengthy.
- if there are several ways to construct a valid object, it can be hard to come up
with unique constructors, since constructor signatures vary only be the number and type
of parameters.
- if a constructor takes two or more parameters of the same type, it may be difficult to
determine what each parameter’s purpose is.
- constructor injection does not lend itself readily to inheritance. A bean’s constructor
will have to pass parameters to super() in order to set private properties in the parent
object.

- note that constructor injection is a surefire way to guarantee that a bean is fully configured
before it is used.

2.3: injecting into bean properties:
- Spring can take advantage of a property’s setter method to configure the property’s value
through setter injection.

2.3.1: injecting simple values:
- Bean properties can be configured in Spring using the <property> element.
- Ex.
<bean id=”kenny”>
<property name=”song” value=”Jingle Bells” />
</bean>

- Spring will determine the correct type for the value based on the property’s type.

2.3.2: Referencing other beans:
<bean id=”saxophone”/>
<bean id=”kenny”>
<property name=”instrument” ref=”saxophone”/>
</bean>

* Injecting inner beans:
- inner beans are beans that are defined within the scope of another bean.
- Ex.
<bean id=”kenny”>
<property name=”song” value=”Jingle Bells”/>
<property name=”instrument”>
<bean/>
</property>
</bean>
- An inner bean is defined by declaring a <bean> element directly as a child of the
<property> element to which it will be injected.
- You can also wire inner beans into constructor arguments.
<bean id=”duke”>
<constructor-arg>
<bean/>
<constructor-arg>
</bean>

- The above highlights the main drawback of using inner beans: they can’t be reused.
Inner beans are only useful for injection once and can’t be referred to by other beans.
- Also using inner-bean definitions has a negative impact on the readability of the XML
in the Spring context files.

2.3.3: Wiring collections:
- Springs offers four types of collection configuration elements that come in handy when
configuring collections of values.
- Spring allows for injecting several kinds of collections:
- <list>        : Wiring a list of values, allowing duplicates.
- <set>         : Wiring a set of values, ensuring no duplicates.
- <map>         : Wiring a collection of name-value pairs where name and value can
be of any type.
- <props>       : Wiring a collection of name-value pairs where the name and value are
both Strings.

- The <list> and <set> elements are useful when configuring properties that are either arrays
or some implementation of java.util.Collection.
- For <map> and <props>, these two elements correspond to collections that are java.util.Map
and java.util.Properties.

* Lists and arrays:
<property name=”instruments”>
<list>
<ref bean=”guitar”/>
<ref bean=”cymbal”/>
<ref bean=”harmonica”/>
</list>
</property>
- The <list> element contains one or more values. here <ref> elements are used to define
the values as references to other beans in the Spring context.
- It’s also possible to use other value-setting Spring elements as teh members of a <list>,
including <value>, <bean>, and <null/>, or another <list>.
- Instrument[] or java.util.List<Instrument>

* Sets:
- <set> ensures that each of its members is unique.
<set> … </set>.
- The <set> element can be used to configure properties whose type is an array or an implementation
of java.util.Collection.

* Maps:
<map>
<entry key=”GUITAR” value-ref=”guitar”/>
<entry key=”CYMBAL” value-ref=”cymbal”/>
<entry key=”HARMONICA” value-ref=”harmonica”/>
</map>
- An <entry> in a <map> is made up of a key and a value, either of which can be a primitive
value or a reference to another bean. These attributes help specify the keys and values of
an <entry>:
- key           : Specifies the key of the map entry as a String.
- key-ref       : Specifies the key of the mpa entry as a reference to a bean in the
Spring context.
- value         : Specifies the value of the map entry as a String.
- value-ref     : Specifies the value of the map entry as a reference to a bean in the
Spring context.
- <map> is only one way to inject key-value pairs into bean properties when either of the
objects is not a String.

* Properties:
<props>
<prop key=”GUITAR”>STRUM STRUM STRUM</prop>
<prop key=”CYMBAL”>CRASH CRASH CRASH</prop>
<prop key=”HARMONICA”>HUM HUM HUM</prop>
</props>

The <props> element constructs a java.util.Properties value where each member is defined by
a <prop> element.

2.3.4: Wiring nothing (null):
- To explicitly wire null into the property. or to override an autowired property value
you can use:
<property name=”someNonNullProperty”><null/></property>

2.4: Autowiring:
- You can have Spring automatically figure out how to wire beans together by setting the
autowire property on each <bean> that you want Spring to autowire.

2.4.1: The four types of autowiring:
- Spring provides four flavors of autowiring:
- byName        : Attempts to find a bean in the container whose name (or ID) is
the same as teh name of the property being wired. if a matching
bean is not found, the property will remain unwired.
- byType        : Attempts to find a single bean in the container whose type matches
the type of the property being wired. if no matching bean is found,
the property will not be wired. if more than one bean matches, an
org.springframework.beans.factory.UnsatisfiedDependencyException
will be thrown.
- constructor   : Tries to match up one or more beans in the container with the parameters
of one of the constructors of the bean being wired. In the event of
ambiguous beans or ambiguous constructors, an org.springframework.
bean.factory.UnsatisfiedDependencyException will be thrown.
- autodetect    : Attempts to autowire by constructor first and then using byType.
Ambiguity is handled the same way as with constructor and byType wiring.

* Autowiring by name:
- EX.
<bean id=”kenny” autowire=”byName” />
In setting the autowire property to byName, you are telling Spring to consider all properties
of kenny and look for beans declared with the same names as the properties.
- The limitation of using byName autowiring is that it assumes that you’ll have a bean whose
name is the same as the property of another bean that you’ll be injecting into.

* Autowiring by type:
- Autowiring using byType works in a similar way to byName, except that instead of considering
a property’s name, the property’s type is examined. When attempting to autowire a property by
type, Spring will look for beans whose type is assignable to the property’s type.
- But there is a limitation to autowiring by type. What happens if Spring finds more than one
bean whose type is assignable to the autowired property?, in such a case, Spring will throw
an exception. so you are allowed to have only one bean configured that matches the autowired
property.

* Using constructor autowiring:
- If your bean is configured using constructor injection, you may choose to put away the
<constructor-arg> elements and let Spring automatically choose constructor arguments from
beans in the Spring context.
- Ex.
<bean id=”duke” autowire=”constructor”/>
The <constructor-arg> elements are gone and the autowire attribute has been set to constructor.
This tells Spring to look at PoeticJuggler’s constructors and try to find beans in the Spring
configuration to satisfy the arguments of one of the constructors.
- Autowiring by constructor shares the same limitations as byType. That is, Spring will not
attempt to guess which bean to autowire when it finds multiple beans that match a
constructor’s arguments. Furthermore, if a constructor has multiple constructors, any of which
can be satisfied by autowiring, Spring will not attempt to guss which constructor to use.

* Autodetect autowiring:
<bean id=”duke” autowire=”autodetect”/>
When a bean has bean configured to autowire by autodetect, Spring will attempt to autowire
by constructor first. if a suitable constructor-bean match can’t be found then Spring will
attempt to autowire by type.

* Autowiring by default:
- By default, beans will not be autowired unless you set the autowire attribute.
However, you can set a default autowiring for all beans within the Spring context by setting
default-autowire on the root <beans> element:
<beans default-autowire=”byName”>
…
</beans>
Set this way, all beans will be autowired using byName unless specified otherwise.

2.4.2: Mixing auto with explicit wiring:
- You explicitly wire some properties with autowiring.
- Mixing automatic and explicit wiring is also a great way to deal with ambiguous autowiring that
may occur when autowiring using byType.
- Note that when using constructor autowiring, you must let Spring wire all of the constructor
arguments – you cannot mix <constructor-arg> elements with constructor autowiring.

2.4.3: To autowire or not to autowire:
- Although it cut down on the amount of manual configuration required when writing the bean
wiring file, it may lead to some problems. As you’ve already seen, autowiring by type or
constructor imposes a restriction where you may only have one bean of a given type.
And autowiring by name forces you to name your beans to match the properties that they’ll
be autowired into.
- The most serious shortcoming of autowiring is that it lacks clarity.

2.5: Controlling bean creating:
- Spring provides a handful of options for creating beans that go beyond what we’ve seen
so far. You can do the following:
- Control how many instances of a specific bean are created, whether it is one
instance for the entire application, one instance per user request, or
a brand-new instance each time teh bean is used.
- Create beans from static factory methods instead of public constructors.
- Initialize a bean after it is created and clean up just before it is
destroyed.

2.5.1: Bean scoping:
- By default, all Spring beans are singletons. That is, when the container dispenses a
bean (either through wiring or as the result of a call to the container’s getBean() method)
it will always hand out the exact same instance of the bean.
- To force Spring to produce a new bean instance each time one is needed, you should declare
the bean’s scope attribute to be prototype.
- Ex.
<bean id=”saxophone” scope=”prototype”/>

- Spring’s bean scopes let you declare the scope under which beans are created without
hardcoding the scoping rules in the bean class itself:
- singleton     : Scopes the bean definition to a single instance per Spring container
(default).
- prototype     : Allows a bean to be instantiated any number of times (once per use).
- request       : Scopes a bean definition to an HTTP request. Only valid when used
with a web-capable Spring context (such as with Spring MVC).
- session       : Scopes a bean definition to an HTTP request.
- global-session: Scopes a bean definition to a global HTTP session. Only valid when
used in a portlet context.

- For the most part, you’ll probably want to leave scoping to the default singleton,
but prototype scope may be useful in situations where you want to use Spring as a factory
for new instances of domain objects.

2.5.2: Creating beans from factory methods:
- Ex.
package com.spring;

public class Stage {
private Stage() {}
private static class StageSingletonHolder {
static Stage instance = new Stage();
}
public static Stage getInstance() {
return StageSingletonHolder.instance;
}
}

- Fortunately, the <bean> element has a factory-method attribute that lets you specify a static
method to be invoked instead of the constructor to create an instance of a class.
- Ex.
<bean id=”theStage” factory-method=”getInstance” />

2.5.3: Initializing and destroying beans:
- To define setup and teardown for a bean, simply declare the <bean> with init-method and/or
destory-method parameters.
- The init-method attribute specifies a method that is to be called on the bean immediately
upon instantiation.
- destroy-method specifies a method that is called just before a bean is removed from the
container.
- Ex.
<bean id=”kenny”
init-method=”tuneInstrument”
destroy-method=”cleanInstrument>
…
</bean>

* Defaulting init-method and destroy-method:
- If many of the beans in a context definition file will have initialization or destroy
methods with the same name, you can take advantage of the default-init-method and
default-destroy-method attributes on the <bean> element:
<beans …
default-init-method=”…”
default-destroy-method=”…”>
…
</beans>
- In this case, we’re asking Spring to initialize all beans in the context definiton file by
calling the … methods and also to tear them down with …, if those methods exist – otherwise
nothing happends.

* InitializingBean and DisposableBean:
- As an option to init-method and destroy-method, we could also rewrite the class to
implement two special Spring interfaces: InitializingBean and DisposableBean.
- The Spring container treats beans that implement these interfaces in a special way by
allowing them to hook into the bean lifecycle.
- The InitializingBean interface mandates that the class implements afterPropertiesSet().
This method will be called once all specified properties for the bean have bean set.
This makes it possible for the bean to perform initialization that can’t be performed
until the bean’s properties have been completely set.
- Similarly, DisposableBean requires that a destroy() method be implemented.
The destroy() method will be called on the other end of the bean’s lifecycle,
when the bean is disposed of by the container.
- The benefit of using these lifecycle interfaces is that Spring container is able to
automatically detect beans that implement them without any external configuration.
However, the disadvantage of implementing these interfaces is that you couple your
application’s beans to Spring’s API.

———————————————————————————————-
Chapter 3: Advanced bean wiring:
———————————————————————————————-

3.1: Declaring parent and child beans:
- The <bean> element provides two special attributes:
- parent        : Indicates the id of a <bean> that will be the parent of the
<bean> with the parent attribute. The parent attribute is to <bean>
what extends is to a Java class.
- abstract      : If set to true, indicates that the <bean> declaration is abstract.
That is, it should never be instantiated by Spring.

3.1.1: Abstracting a base bean type:
- If you have two <bean>s declared in Spring with virtually the same XML. or the only
difference between these two <bean>s are their ids.
- When you have two beans with the same type and have properties that are injected with
the same values.
- Ex.
<bean id=”base” abstract=”true”>
<property name=”instrument” ref=”saxophone” />
<property name=”song” value=”Jingle Bells” />
</bean>

- The true attribute for abstract tells Spring to not try to instantiate this bean.
even if it is explicitly requested from the container. In many ways this is the same
as an abstract class in Java, which can’t be instantiated.
- We are now able to declare the kenny and david beans as follows:
<bean id=”kenny” parent=”base” />
<bean id=”david” parent=”base” />
- The parent attribute indicates that both the kenny and david beans will inherit their
definition from the base bean.
- The parent bean doesn’t have to be abstract. It’s entirely possible to create sub-beans
that extend a concrete bean.

* Overriding inherited properties:
- Ex.
<bean id=”frank” parent=”base”>
<property name=”song” value=”Mary had a little lamb” />
</bean>

3.1.2: