1. In a Spring-based application, your application objects will live within the Spring con-
tainer. the container will create the objects, wire them
together, configure them, and manage their complete lifecycle from cradle to grave.
The container is at the core of the Spring Framework. Spring’s container uses
dependency injection (DI) to manage the components that make up an application.
This includes creating associations between collaborating components.
There’s no single Spring container. Spring comes with several container implementa-
tions 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) build on the notion
of a bean factory by providing application framework services, such as the ability to
resolve textual messages from a properties file and the ability to publish application
events to interested event listeners.
Although it’s possible to work with Spring using either bean factories or application
contexts, bean factories are often too low-level for most applications. Therefore, appli-
cation contexts are preferred over bean factories.
2.
Spring comes with several flavors of application context. The three that you’ll most
likely encounter are
ClassPathXmlApplicationContext—Loads a context definition from an XML
file located in the classpath (including JAR files), 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.
4.
The picture on page 19
1 Spring instantiates the bean.
2 Spring injects values and bean references into the bean’s properties.
3 If the bean implements BeanNameAware, Spring passes the bean’s ID to the set-
BeanName() method.
4 If the bean implements BeanFactoryAware, Spring calls the setBeanFactory()
method, passing in the bean factory itself.
5 If the bean implements ApplicationContextAware, Spring will call the set-
ApplicationContext() method, passing in a reference to the enclosing appli-
cation context. 6 If any of the beans implement the BeanPostProcessor interface, Spring calls
their postProcessBeforeInitialization() method.
7 If any beans implement the InitializingBean interface, Spring calls their
afterPropertiesSet() method. Similarly, if the bean was declared with an
init-method, then the specified initialization method will be called.
8 If there are any beans that implement BeanPostProcessor, Spring will call their
postProcessAfterInitialization() method.
9 At this point, the bean is ready to be used by the application and will remain in
the application context until the application context is destroyed.
10 If any beans implement the DisposableBean interface, then Spring will call
their destroy() methods. Likewise, if any bean was declared with a destroy-
method, then the specified method will be called.
5.
the Spring Framework is focused on simplifying enterprise Java devel-
opment through dependency injection, aspect-oriented programming, and boiler-
plate reduction.
6.
the <bean> element has a factory-method attribute that lets you spec-
ify a static method to be invoked instead of the constructor to create an instance of a
class.
<bean id="theStage" class="com.springinaction.springidol.Stage" factory-method="getInstance" />
7.
By default, all Spring beans are singletons. When the container dispenses a bean
(either through wiring or as the result of a call to the container’s getBean() method)
it’ll always hand out the exact same instance of the bean. When declaring a <bean> in Spring, you have the option of declaring a scope for
that 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.
8.
Unlike true singletons, which guarantee only a single
instance of a class per classloader, Spring’s singleton beans only guarantee a single
instance of the bean definition per the application context—nothing is stopping you
from instantiating that same class in a more conventional way or even defining several
<bean> declarations that instantiate the same class.
9.
To define setup and teardown for a bean, simply declare the <bean> with init-
method and/or destroy-method parameters.
10.
<constructor-arg ref="quest"/>
<constructor-arg value="15"/>
<property name="song" value="JingleBells"/>
<property name="instrument" ref="saxophone"/>
<property name="instrument">
<bean class="org.springinaction.springidol.Saxophone"/>
</property>
list/set/map/props(both strings)
<property name="instruments">
<list>
<refbean="guitar"/>
<refbean="cymbal"/>
<refbean="harmonica"/>
</list>
</property>
<property name="instruments">
<map>
<entry key="GUITAR" value-ref="guitar"/>
<entry key="CYMBAL" value-ref="cymbal"/>
<entry key="HARMONICA value-ref="harmonica"/>
</map>
</property>
<property name="instruments">
<props>
<prop key="GUITAR">STRUMSTRUMSTRUM</prop>
<prop key="CYMBAL">CRASHCRASHCRASH</prop>
<prop key="HARMONICA">HUMHUMHUM</prop>
</props>
</property>
<propertyname="someNonNullProperty"><null/></property>
11. You’re probably rolling your eyes and thinking, “What’s this guy talking about?
What if, for some twisted reason, you want to force that property to be null?
12.
What if we want to wire properties with values that aren’t known until runtime?
<property name="count" value="#{5}"/>
The #{} markers are a clue to Spring that the content that they contain is a SpEL
expression. They could be mixed with non-SpEL values as well:
<property name="message" value="The value is #{5}"/>
Literal String values can also be expressed in SpEL with either single or double quote
marks. For example, to wire a literal String value into a bean property, we could
express it like this:
<property name="name" value="#{'Chuck'}"/>
Or if you were using single quote marks for XML attribute values, then you’d want to
use double quotes in the SpEL expression:
<property name='name' value='#{"Chuck"}'/>
you could use SpEL to wire one bean into another bean’s property by
using the bean ID as the SpEL expression:
<property name="instrument" value="#{saxophone}"/>
same as <property name="instrument" ref="saxophone"/>
<property name="song" value="#{kenny.song}"/>
Referencing a bean’s properties isn’t the
only thing you can do with a bean. You could also invoke a method.
<property name="song" value="#{songSelector.selectSong()?.toUpperCase()}"/>
<property name="multiplier" value="#{T(java.lang.Math).PI}"/>
here’s how to wire a random number (between 0 and 1) into a bean property:
<property name="randomNumber" value="#{T(java.lang.Math).random()}"/>
<property name="fullName" value="#{performer.firstName + ' ' + performer.lastName}"/>
to compare two numbers for equality, you can use the double-equal(==) operator:
<property name="equal" value="#{counter.total==100}"/>
Equals == eq
Less than < lt
Less than or equals <= le
Greater than > gt
Greater than or equals >= ge
<property name="song" value="#{kenny.song !=null?kenny.song:'Greensleeves'}"/>
<property name="validEmail" value="#{admin.email matches '[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.com'}"/>
13.
Autowiring helps reduce or even eliminate the need for <property> and
<constructor-arg> elements by letting Spring automatically figure out how
to wire bean dependencies.
Autodiscovery takes autowiring a step further by letting Spring figure out
which classes should be configured as Spring beans, reducing the need for
the <bean> element.
14.
Spring provides four flavors of autowiring:
byName—Attempts to match all properties of the autowired bean with beans
that have the same name (or ID) as the properties. Properties for which there’s
no matching bean will remain unwired.
byType—Attempts to match all properties of the autowired bean with beans
whose types are assignable to the properties. Properties for which there’s no
matching bean will remain unwired.
constructor—Tries to match up a constructor of the autowired bean with
beans whose types are assignable to the constructor arguments.
autodetect—Attempts to apply constructor autowiring first. If that fails,
byType will be tried.
15.
<bean id="kenny"
class="com.springinaction.springidol.Instrumentalist"
autowire="byName">
<property name="song" value="JingleBells"/>
</bean>
What happens if Spring finds more
than one bean whose type is assignable to the autowired property? In such a case,
Spring isn’t going to guess which bean to autowire and will instead throw an exception.
To overcome ambiguities with autowiring by type, Spring offers two options: you
can either identify a primary candidate for autowiring or you can eliminate beans
from autowiring candidacy. But here’s the weird side of the primary attribute: it defaults to true. That means
that all autowire candidates will be primary (and thus none will be preferred). So, to
use primary, you’ll need to set it to false for all of the beans that are not the primary
choice.
default-autowire attribute to the root <beans> element
16.
Annotation wiring isn’t turned on in the Spring container by default.
The simplest way to do that is with the <context:annotation-config> element
from Spring’s context configuration namespace. <context:annotation-config> tells Spring that you intend to use annotation-based
wiring in Spring.
Spring 3 supports a few different annotations for autowiring:
Spring’s own @Autowired annotation
The @Inject annotation from JSR-330
The @Resource annotation from JSR-250
Just like @Autowired, @Inject can be used to autowire properties, methods, and con-
structors. Unlike @Autowired, @Inject doesn’t have a required attribute. Therefore,
@Inject-annotated dependencies are expected to be fulfilled, failing with an excep-
tion if they’re not.
@Inject’s answer to
the @Qualifier annotation is the @Named annotation.
@Inject
@Named("guitar")
private Instrumentinstrument;
17.
When you added <context:annotation-config> to your Spring configuration, you
told Spring that you wanted it to honor a certain set of annotations in the beans that
you declared and to use those beans to guide bean wiring. Even though <context:
annotation-config> can go a long way toward eliminating most uses of <property>
and <constructor-arg> elements from your Spring configuration, you still must
explicitly declare beans using <bean>.
But Spring has another trick up its sleeve. The <context:component-scan> element
does everything that <context:annotation-config> does, plus it configures
Spring to automatically discover beans and declare them for you.
<context:component-scan
base-package="com.springinaction.springidol">
</context:component-scan>
The <context:component-scan> element works by scanning a package and all of its
subpackages, looking for classes that could be automatically registered as beans in the
Spring container. The base-package attribute tells <context:component-scan> the
package to start its scan from.
By default, <context:component-scan> looks for classes that are annotated with one
of a handful of special stereotype annotations:
@Component—A general-purpose stereotype annotation indicating that the class
is a Spring component
@Controller—Indicates that the class defines a Spring MVC controller
@Repository—Indicates that the class defines a data repository
@Service—Indicates that the class defines a service
Any custom annotation that is itself annotated with @Component
As it turns out, <context:component-scan> is flexible with regard to how it scans for
bean candidates. By adding <context:include-filter> and/or <context:exclude-
filter> subelements to <context:component-scan>, you can tweak component-
scanning behavior to your heart’s content.
The @Configuration annotation serves as a clue to Spring that this class will contain
one or more Spring bean declarations.
18.
Because it’s based on dynamic proxies, Spring only supports
method join points. This is in contrast to some other AOP frameworks, such as AspectJ
and JBoss, which provide field and constructor join points in addition to method
pointcuts.
19.
And as of Spring 3.0, support for older versions of Java (prior to Java 5)
has been dropped—so there’s almost no reason to choose the plain JdbcTemplate
over SimpleJdbcTemplate. In light of these changes, we’ll focus solely on Simple-
JdbcTemplate in this chapter.
No comments:
Post a Comment