List of Figures

Chapter 1. Springing into action

Figure 1.1. Dependency injection involves giving an object its dependencies as opposed to an object having to acquire those dependencies on its own.

Figure 1.2. Calls to systemwide concerns such as logging and security are often scattered about in modules where those concerns are not their primary concern.

Figure 1.3. Using AOP, systemwide concerns blanket the components that they impact. This leaves the application components to focus on their specific business functionality.

Figure 1.4. In a Spring application, objects are created, wired together, and live within the Spring container.

Figure 1.5. A bean goes through several steps between creation and destruction in the Spring container. Each step is an opportunity to customize how the bean is managed in Spring.

Figure 1.6. The JAR files that come with the Spring Framework distribution

Figure 1.7. The Spring Framework is made up of six well-defined modules.

Chapter 2. Wiring beans

Figure 2.1. Referring to another bean’s property using the Spring Expression Language

Chapter 3. Minimizing XML configuration in Spring

Figure 3.1. When autowiring by name, a bean’s name is matched against properties that have the same name.

Figure 3.2. Autowiring by type matches beans to properties of the same type.

Figure 3.3. When autowired by constructor, the dukePoeticJuggler is instantiated with the constructor that takes a Poem argument.

Chapter 4. Aspect-oriented Spring

Figure 4.1. Aspects modularize cross-cutting concerns, applying logic that spans multiple application objects.

Figure 4.2. An aspect’s functionality (advice) is woven into a program’s execution at one or more join points.

Figure 4.3. Spring aspects are implemented as proxies that wrap the target object. The proxy handles method calls, performs additional aspect logic, and then invokes the target method.

Figure 4.4. Selecting the Instrument's play() method with an AspectJ pointcut expression

Figure 4.5. Limiting a pointcut’s reach using the within() designator

Figure 4.6. The Audience aspect includes four bits of advice which weave advice logic around methods that match the aspect’s pointcut.

Figure 4.7. With Spring AOP, you can introduce new methods to a bean. A proxy intercepts the calls and delegates to a different object that implements the method.

Figure 4.8. Aspects need injection, too. Spring can inject AspectJ aspects with dependencies just as if they were another bean.

Chapter 5. Hitting the database

Figure 5.1. Service objects don’t handle their own data access. Instead, they delegate data access to DAOs. The DAO’s interface keeps it loosely coupled to the service object.

Figure 5.2. Spring’s DAO template classes take responsibility for the common data access duties. For the application-specific tasks, it calls back into a custom DAO callback object.

Figure 5.3. The relationship between an application DAO and Spring’s DAO support and template classes

Figure 5.4. Spring’s DAO support classes define a placeholder for the JDBC template objects so that subclasses won’t have to manage their own JDBC templates.

Chapter 6. Managing transactions

Figure 6.1. The steps involved when purchasing a movie ticket should be all or nothing. If every step is successful, then the entire transaction is successful. Otherwise, the steps should be rolled back—as if they never happened.

Figure 6.2. Spring’s transaction managers delegate transaction-management responsibility to platform-specific transaction implementations.

Figure 6.3. Declarative transactions are defined in terms of propagation behavior, isolation level, read-only hints, timeout, and rollback rules.

Chapter 7. Building web applications with Spring MVC

Figure 7.1. The web layer of the Spitter application includes two resource-oriented controllers along with a couple of utility controllers.

Figure 7.2. The web layer of the Spittle application includes two resource-oriented controllers along with a couple of utility controllers.

Figure 7.3. InternalResourceViewResolver resolves a view template’s path by attaching a specified prefix and suffix to the logical view name.

Figure 7.4. The Spitter application’s home page displays a welcome message along with a list of recent spittles.

Figure 7.5. When taken together with other Tiles elements, list.jsp shows a list of spittles for a given user.

Figure 7.6. @RequestMapping’s params attribute can limit a handler method to only handling requests with certain parameters.

Figure 7.7. With the <sf:errors> JSP tag on the registration page, validation problems will be shown to the user for them to fix and try again.

Figure 7.8. A file selection field in the Spitter registration form will enable users to put a face on their profile.

Chapter 8. Working with Spring Web Flow

Figure 8.1. When using a flow location pattern, the path to the flow definition file relative to the base path will be used as the flow’s ID.

Figure 8.2. The process of ordering a pizza boils down to a simple flow.

Figure 8.3. The flow for identifying a customer has a few more twists than the pizza flow.

Figure 8.4. Pizzas are added via the order subflow.

Figure 8.5. The final step in placing a pizza order is to take payment from the customer through the payment subflow.

Chapter 9. Securing Spring

Figure 9.1. DelegatingFilterProxy proxies filter handling to a delegate filter bean in the Spring application context.

Chapter 10. Working with remote services

Figure 10.1. A third-party client can interact with the Spitter application by making remote calls to a service exposed by Spitter.

Figure 10.2. In Spring, remote services are proxied so that they can be wired into client code as if they were any other Spring bean.

Figure 10.3. Spring-managed beans can be exported as remote services using remote exporters.

Figure 10.4. RmiServiceExporter turns POJOs into RMI services by wrapping them in a service adapter and binding the service adapter to the RMI registry.

Figure 10.5. RmiProxyFactoryBean produces a proxy object that talks to remote RMI services on behalf of the client. The client talks to the proxy through the service’s interface as if the remote service were just a local POJO.

Figure 10.6. HessianService-Exporter is a Spring MVC controller that exports a POJO as a Hessian service by receiving Hessian requests and translating them into calls to the POJO.

Figure 10.7. HessianProxyFactoryBean and BurlapProxyFactoryBean produce proxy objects that talk to a remote service over HTTP (Hessian in binary, Burlap in XML).

Figure 10.8. HttpInvokerServiceExporter works much like its Hessian and Burlap cousins, receiving requests from a Spring MVC Dispatcher-Servlet and translating them into method calls on a Spring-managed bean.

Figure 10.9. HttpInvokerProxyFactoryBean is a proxy factory bean that produces a proxy for remoting with a Spring-specific HTTP-based protocol.

Figure 10.10. JaxWsPortProxyFactoryBean produces proxies that talk to remote web services. These proxies can then be wired into other beans as if they were local POJOs.

Chapter 11. Giving Spring some REST

Figure 11.1. A RESTless URL is action-oriented and doesn’t identify or locate a resource.

Figure 11.2. A RESTful URL is resource-oriented, both identifying and locating a resource.

Figure 11.3. HiddenHttpMethodFilter transforms POST-masquerading PUT and DELETE requests into their true form.

Chapter 12. Messaging in Spring

Figure 12.1. When communicating synchronously, the client must wait for the message. operation to complete.

Figure 12.2. Asynchronous communication is a no-wait form of communication.

Figure 12.3. A message queue decouples a message sender from the message receiver. Though a queue may have several receivers, each message is picked up by exactly one receiver.

Figure 12.4. Like queues, topics decouple message senders from message receivers. Unlike queues, a topic message could be delivered to many topic subscribers.

Figure 12.5. JmsTemplate deals with the complexities of sending a message on behalf of the sender.

Figure 12.6. Receiving messages from a topic or queue using JmsTemplate is as simple as calling the receive() method. JmsTemplate takes care of the rest.

Figure 12.7. A message listener container listens to a queue/topic. When a message arrives, it’s forwarded to a message listener (such as a message-driven POJO).

Chapter 13. Managing Spring beans with JMX

Figure 13.1. Spring’s MBeanExporter exports the properties and methods of Spring beans as JMX attributes and operations in an MBean server. From there, a JMX management tool such as JConsole can look inside the running application.

Figure 13.2. HomeController exported as an MBean and seen through the eyes of JConsole

Figure 13.3. After specifying which methods are exported in the HomeController MBean, the showHomePage() method is no longer a managed operation.

Figure 13.4. MBeanProxyFactoryBean produces a proxy to a remote MBean. The proxy’s client can then interact with the remote MBean as if it were a locally configured POJO.

Figure 13.5. JMX notifications enable MBeans to communicate proactively with the outside world.

Chapter 14. Odds and ends

Figure 14.1. A property overrider determines which bean properties to override by mapping keys from a properties file to a bean ID and a property name.

Figure 14.2. Using conventional JNDI to retrieve dependencies means that an object is coupled to JNDI, making it difficult to use the object anywhere that JNDI isn’t available.

Figure 14.3. <jee:jndi-lookup> looks up an object from JNDI, making it available as a bean in the Spring application context. From there, it can be wired into any other object that depends on it.

Figure 14.4. Spring’s MailSender interface is the primary component of Spring’s email abstraction API. It sends an email to a mail server for delivery.

Figure 14.5. A Velocity template and some embedded images can dress up an otherwise ho-hum email.