站内搜索: 请输入搜索关键词
当前页面: 在线文档首页 > Spring Framework reference 2.0.5 参考手册英文版

The Spring Framework - Reference Documentation - Spring Framework reference 2.0.5 参考手册英文版

The Spring Framework - Reference Documentation

Authors

Rod Johnson, Juergen Hoeller, Alef Arendsen, Colin Sampaleanu, Rob Harrop, Thomas Risberg, Darren Davison, Dmitriy Kopylenko, Mark Pollack, Thierry Templier, Erwin Vervaet, Portia Tung, Ben Hale, Adrian Colyer, John Lewis, Costin Leau, Rick Evans

2.0.5

Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.
Preface
1. Introduction
1.1. Overview
1.2. Usage scenarios
2. What's new in Spring 2.0?
2.1. Introduction
2.2. The Inversion of Control (IoC) container
2.2.1. Easier XML configuration
2.2.2. New bean scopes
2.2.3. Extensible XML authoring
2.3. Aspect Oriented Programming (AOP)
2.3.1. Easier AOP XML configuration
2.3.2. Support for @AspectJ aspects
2.4. The Middle Tier
2.4.1. Easier configuration of declarative transactions in XML
2.4.2. JPA
2.4.3. Asynchronous JMS
2.4.4. JDBC
2.5. The Web Tier
2.5.1. A form tag library for Spring MVC
2.5.2. Sensible defaulting in Spring MVC
2.5.3. Portlet framework
2.6. Everything else
2.6.1. Dynamic language support
2.6.2. JMX
2.6.3. Task scheduling
2.6.4. Java 5 (Tiger) support
2.7. Migrating to Spring 2.0
2.7.1. Changes
2.7.1.1. Jar packaging
2.7.1.2. XML configuration
2.7.1.3. Deprecated classes and methods
2.7.1.4. Apache OJB
2.7.1.5. iBatis
2.7.1.6. UrlFilenameViewController
2.8. Updated sample applications
2.9. Improved documentation
I. Core Technologies
3. The IoC container
3.1. Introduction
3.2. Basics - containers and beans
3.2.1. The container
3.2.1.1. Configuration metadata
3.2.2. Instantiating a container
3.2.2.1. Composing XML-based configuration metadata
3.2.3. The beans
3.2.3.1. Naming beans
3.2.3.2. Instantiating beans
3.2.4. Using the container
3.3. Dependencies
3.3.1. Injecting dependencies
3.3.1.1. Setter Injection
3.3.1.2. Constructor Injection
3.3.1.3. Some examples
3.3.2. Constructor Argument Resolution
3.3.2.1. Constructor Argument Type Matching
3.3.2.2. Constructor Argument Index
3.3.3. Bean properties and constructor arguments detailed
3.3.3.1. Straight values (primitives, Strings, etc.)
3.3.3.2. References to other beans (collaborators)
3.3.3.3. Inner beans
3.3.3.4. Collections
3.3.3.5. Nulls
3.3.3.6. Shortcuts and other convenience options for XML-based configuration metadata
3.3.3.7. Compound property names
3.3.4. Using depends-on
3.3.5. Lazily-instantiated beans
3.3.6. Autowiring collaborators
3.3.6.1. Excluding a bean from being available for autowiring
3.3.7. Checking for dependencies
3.3.8. Method Injection
3.3.8.1. Lookup method injection
3.3.8.2. Arbitrary method replacement
3.4. Bean scopes
3.4.1. The singleton scope
3.4.2. The prototype scope
3.4.3. The other scopes
3.4.3.1. Initial web configuration
3.4.3.2. The request scope
3.4.3.3. The session scope
3.4.3.4. The global session scope
3.4.3.5. Scoped beans as dependencies
3.4.4. Custom scopes
3.4.4.1. Creating your own custom scope
3.4.4.2. Using a custom scope
3.5. Customizing the nature of a bean
3.5.1. Lifecycle interfaces
3.5.1.1. Initialization callbacks
3.5.1.2. Destruction callbacks
3.5.2. Knowing who you are
3.5.2.1. BeanFactoryAware
3.5.2.2. BeanNameAware
3.6. Bean definition inheritance
3.7. Container extension points
3.7.1. Customizing beans using BeanPostProcessors
3.7.1.1. Example: Hello World, BeanPostProcessor-style
3.7.1.2. Example: The RequiredAnnotationBeanPostProcessor
3.7.2. Customizing configuration metadata with BeanFactoryPostProcessors
3.7.2.1. Example: the PropertyPlaceholderConfigurer
3.7.2.2. Example: the PropertyOverrideConfigurer
3.7.3. Customizing instantiation logic using FactoryBeans
3.8. The ApplicationContext
3.8.1. Internationalization using MessageSources
3.8.2. Events
3.8.3. Convenient access to low-level resources
3.8.4. Convenient ApplicationContext instantiation for web applications
3.9. Glue code and the evil singleton
3.9.1. Using the Singleton-helper classes
4. Resources
4.1. Introduction
4.2. The Resource interface
4.3. Built-in Resource implementations
4.3.1. UrlResource
4.3.2. ClassPathResource
4.3.3. FileSystemResource
4.3.4. ServletContextResource
4.3.5. InputStreamResource
4.3.6. ByteArrayResource
4.4. The ResourceLoader
4.5. The ResourceLoaderAware interface
4.6. Resources as dependencies
4.7. Application contexts and Resource paths
4.7.1. Constructing application contexts
4.7.1.1. Constructing ClassPathXmlApplicationContext instances - shortcuts
4.7.2. Wildcards in application context constructor resource paths
4.7.2.1. Ant-style Patterns
4.7.2.2. The classpath*: prefix
4.7.2.3. Other notes relating to wildcards
4.7.3. FileSystemResource caveats
5. Validation, Data-binding, the BeanWrapper, and PropertyEditors
5.1. Introduction
5.2. Validation using Spring's Validator interface
5.3. Resolving codes to error messages
5.4. Bean manipulation and the BeanWrapper
5.4.1. Setting and getting basic and nested properties
5.4.2. Built-in PropertyEditor implementations
5.4.2.1. Registering additional custom PropertyEditors
6. Aspect Oriented Programming with Spring
6.1. Introduction
6.1.1. AOP concepts
6.1.2. Spring AOP capabilities and goals
6.1.3. AOP Proxies
6.2. @AspectJ support
6.2.1. Enabling @AspectJ Support
6.2.2. Declaring an aspect
6.2.3. Declaring a pointcut
6.2.3.1. Supported Pointcut Designators
6.2.3.2. Combining pointcut expressions
6.2.3.3. Sharing common pointcut definitions
6.2.3.4. Examples
6.2.4. Declaring advice
6.2.4.1. Before advice
6.2.4.2. After returning advice
6.2.4.3. After throwing advice
6.2.4.4. After (finally) advice
6.2.4.5. Around advice
6.2.4.6. Advice parameters
6.2.4.7. Advice ordering
6.2.5. Introductions
6.2.6. Aspect instantiation models
6.2.7. Example
6.3. Schema-based AOP support
6.3.1. Declaring an aspect
6.3.2. Declaring a pointcut
6.3.3. Declaring advice
6.3.3.1. Before advice
6.3.3.2. After returning advice
6.3.3.3. After throwing advice
6.3.3.4. After (finally) advice
6.3.3.5. Around advice
6.3.3.6. Advice parameters
6.3.3.7. Advice ordering
6.3.4. Introductions
6.3.5. Aspect instantiation models
6.3.6. Advisors
6.3.7. Example
6.4. Choosing which AOP declaration style to use
6.4.1. Spring AOP or full AspectJ?
6.4.2. @AspectJ or XML for Spring AOP?
6.5. Mixing aspect types
6.6. Proxying mechanisms
6.6.1. Understanding AOP proxies
6.7. Programmatic creation of @AspectJ Proxies
6.8. Using AspectJ with Spring applications
6.8.1. Using AspectJ to dependency inject domain objects with Spring
6.8.1.1. Unit testing @Configurable objects
6.8.1.2. Working with multiple application contexts
6.8.2. Other Spring aspects for AspectJ
6.8.3. Configuring AspectJ aspects using Spring IoC
6.8.4. Using AspectJ Load-time weaving (LTW) with Spring applications
6.9. Further Resources
7. Spring AOP APIs
7.1. Introduction
7.2. Pointcut API in Spring
7.2.1. Concepts
7.2.2. Operations on pointcuts
7.2.3. AspectJ expression pointcuts
7.2.4. Convenience pointcut implementations
7.2.4.1. Static pointcuts
7.2.4.2. Dynamic pointcuts
7.2.5. Pointcut superclasses
7.2.6. Custom pointcuts
7.3. Advice API in Spring
7.3.1. Advice lifecycles
7.3.2. Advice types in Spring
7.3.2.1. Interception around advice
7.3.2.2. Before advice
7.3.2.3. Throws advice
7.3.2.4. After Returning advice
7.3.2.5. Introduction advice
7.4. Advisor API in Spring
7.5. Using the ProxyFactoryBean to create AOP proxies
7.5.1. Basics
7.5.2. JavaBean properties
7.5.3. JDK- and CGLIB-based proxies
7.5.4. Proxying interfaces
7.5.5. Proxying classes
7.5.6. Using 'global' advisors
7.6. Concise proxy definitions
7.7. Creating AOP proxies programmatically with the ProxyFactory
7.8. Manipulating advised objects
7.9. Using the "autoproxy" facility
7.9.1. Autoproxy bean definitions
7.9.1.1. BeanNameAutoProxyCreator
7.9.1.2. DefaultAdvisorAutoProxyCreator
7.9.1.3. AbstractAdvisorAutoProxyCreator
7.9.2. Using metadata-driven auto-proxying
7.10. Using TargetSources
7.10.1. Hot swappable target sources
7.10.2. Pooling target sources
7.10.3. Prototype target sources
7.10.4. ThreadLocal target sources
7.11. Defining new Advice types
7.12. Further resources
8. Testing
8.1. Introduction
8.2. Unit testing
8.3. Integration testing
8.3.1. Context management and caching
8.3.2. Dependency Injection of test fixtures
8.3.2.1. Field level injection
8.3.3. Transaction management
8.3.4. Convenience variables
8.3.5. Java5+ specific support
8.3.5.1. Annotations
8.3.6. PetClinic example
8.4. Further Resources
II. Middle Tier Data Access
9. Transaction management
9.1. Introduction
9.2. Motivations
9.3. Key abstractions
9.4. Resource synchronization with transactions
9.4.1. High-level approach
9.4.2. Low-level approach
9.4.3. TransactionAwareDataSourceProxy
9.5. Declarative transaction management
9.5.1. Understanding the Spring Framework's declarative transaction implementation
9.5.2. A first example
9.5.3. Rolling back
9.5.4. Configuring different transactional semantics for different beans
9.5.5. <tx:advice/> settings
9.5.6. Using @Transactional
9.5.6.1. @Transactional settings
9.5.7. Advising transactional operations
9.5.8. Using @Transactional with AspectJ
9.6. Programmatic transaction management
9.6.1. Using the TransactionTemplate
9.6.1.1. Specifying transaction settings
9.6.2. Using the PlatformTransactionManager
9.7. Choosing between programmatic and declarative transaction management
9.8. Application server-specific integration
9.8.1. BEA WebLogic
9.8.2. IBM WebSphere
9.9. Solutions to common problems
9.9.1. Use of the wrong transaction manager for a specific DataSource
9.10. Further Resources
10. DAO support
10.1. Introduction
10.2. Consistent exception hierarchy
10.3. Consistent abstract classes for DAO support
11. Data access using JDBC
11.1. Introduction
11.1.1. The package hierarchy
11.2. Using the JDBC Core classes to control basic JDBC processing and error handling
11.2.1. JdbcTemplate
11.2.1.1. Examples
11.2.1.2. JdbcTemplate idioms (best practices)
11.2.2. NamedParameterJdbcTemplate
11.2.3. SimpleJdbcTemplate
11.2.4. DataSource
11.2.5. SQLExceptionTranslator
11.2.6. Executing statements
11.2.7. Running Queries
11.2.8. Updating the database
11.3. Controlling database connections
11.3.1. DataSourceUtils
11.3.2. SmartDataSource
11.3.3. AbstractDataSource
11.3.4. SingleConnectionDataSource
11.3.5. DriverManagerDataSource
11.3.6. TransactionAwareDataSourceProxy
11.3.7. DataSourceTransactionManager
11.4. Modeling JDBC operations as Java objects
11.4.1. SqlQuery
11.4.2. MappingSqlQuery
11.4.3. SqlUpdate
11.4.4. StoredProcedure
11.4.5. SqlFunction
12. Object Relational Mapping (ORM) data access
12.1. Introduction
12.2. Hibernate
12.2.1. Resource management
12.2.2. SessionFactory setup in a Spring container
12.2.3. The HibernateTemplate
12.2.4. Implementing Spring-based DAOs without callbacks
12.2.5. Implementing DAOs based on plain Hibernate3 API
12.2.6. Programmatic transaction demarcation
12.2.7. Declarative transaction demarcation
12.2.8. Transaction management strategies
12.2.9. Container resources versus local resources
12.2.10. Spurious application server warnings when using Hibernate
12.3. JDO
12.3.1. PersistenceManagerFactory setup
12.3.2. JdoTemplate and JdoDaoSupport
12.3.3. Implementing DAOs based on the plain JDO API
12.3.4. Transaction management
12.3.5. JdoDialect
12.4. Oracle TopLink
12.4.1. SessionFactory abstraction
12.4.2. TopLinkTemplate and TopLinkDaoSupport
12.4.3. Implementing DAOs based on plain TopLink API
12.4.4. Transaction management
12.5. iBATIS SQL Maps
12.5.1. Setting up the SqlMapClient
12.5.2. Using SqlMapClientTemplate and SqlMapClientDaoSupport
12.5.3. Implementing DAOs based on plain iBATIS API
12.6. JPA
12.6.1. JPA setup in a Spring environment
12.6.1.1. LocalEntityManagerFactoryBean
12.6.1.2. LocalContainerEntityManagerFactoryBean
12.6.1.3. Dealing with multiple persistence units
12.6.2. JpaTemplate and JpaDaoSupport
12.6.3. Implementing DAOs based on plain JPA
12.6.4. Exception Translation
12.7. Transaction Management
12.8. JpaDialect
III. The Web
13. Web MVC framework
13.1. Introduction
13.1.1. Pluggability of other MVC implementations
13.1.2. Features of Spring Web MVC
13.2. The DispatcherServlet
13.3. Controllers
13.3.1. AbstractController and WebContentGenerator
13.3.2. Other simple controllers
13.3.3. The MultiActionController
13.3.4. Command controllers
13.4. Handler mappings
13.4.1. BeanNameUrlHandlerMapping
13.4.2. SimpleUrlHandlerMapping
13.4.3. Intercepting requests - the HandlerInterceptor interface
13.5. Views and resolving them
13.5.1. Resolving views - the ViewResolver interface
13.5.2. Chaining ViewResolvers
13.5.3. Redirecting to views
13.5.3.1. RedirectView
13.5.3.2. The redirect: prefix
13.5.3.3. The forward: prefix
13.6. Using locales
13.6.1. AcceptHeaderLocaleResolver
13.6.2. CookieLocaleResolver
13.6.3. SessionLocaleResolver
13.6.4. LocaleChangeInterceptor
13.7. Using themes
13.7.1. Introduction
13.7.2. Defining themes
13.7.3. Theme resolvers
13.8. Spring's multipart (fileupload) support
13.8.1. Introduction
13.8.2. Using the MultipartResolver
13.8.3. Handling a file upload in a form
13.9. Using Spring's form tag library
13.9.1. Configuration
13.9.2. The form tag
13.9.3. The input tag
13.9.4. The checkbox tag
13.9.5. The radiobutton tag
13.9.6. The password tag
13.9.7. The select tag
13.9.8. The option tag
13.9.9. The options tag
13.9.10. The textarea tag
13.9.11. The hidden tag
13.9.12. The errors tag
13.10. Handling exceptions
13.11. Convention over configuration
13.11.1. The Controller - ControllerClassNameHandlerMapping
13.11.2. The Model - ModelMap (ModelAndView)
13.11.3. The View - RequestToViewNameTranslator
13.12. Further Resources
14. Integrating view technologies
14.1. Introduction
14.2. JSP & JSTL
14.2.1. View resolvers
14.2.2. 'Plain-old' JSPs versus JSTL
14.2.3. Additional tags facilitating development
14.3. Tiles
14.3.1. Dependencies
14.3.2. How to integrate Tiles
14.3.2.1. InternalResourceViewResolver
14.3.2.2. ResourceBundleViewResolver
14.4. Velocity & FreeMarker
14.4.1. Dependencies
14.4.2. Context configuration
14.4.3. Creating templates
14.4.4. Advanced configuration
14.4.4.1. velocity.properties
14.4.4.2. FreeMarker
14.4.5. Bind support and form handling
14.4.5.1. The bind macros
14.4.5.2. simple binding
14.4.5.3. form input generation macros
14.4.5.4. HTML escaping and XHTML compliance
14.5. XSLT
14.5.1. My First Words
14.5.1.1. Bean definitions
14.5.1.2. Standard MVC controller code
14.5.1.3. Convert the model data to XML
14.5.1.4. Defining the view properties
14.5.1.5. Document transformation
14.5.2. Summary
14.6. Document views (PDF/Excel)
14.6.1. Introduction
14.6.2. Configuration and setup
14.6.2.1. Document view definitions
14.6.2.2. Controller code
14.6.2.3. Subclassing for Excel views
14.6.2.4. Subclassing for PDF views
14.7. JasperReports
14.7.1. Dependencies
14.7.2. Configuration
14.7.2.1. Configuring the ViewResolver
14.7.2.2. Configuring the Views
14.7.2.3. About Report Files
14.7.2.4. Using JasperReportsMultiFormatView
14.7.3. Populating the ModelAndView
14.7.4. Working with Sub-Reports
14.7.4.1. Configuring Sub-Report Files
14.7.4.2. Configuring Sub-Report Data Sources
14.7.5. Configuring Exporter Parameters
15. Integrating with other web frameworks
15.1. Introduction
15.2. Common configuration
15.3. JavaServer Faces
15.3.1. DelegatingVariableResolver
15.3.2. FacesContextUtils
15.4. Struts
15.4.1. ContextLoaderPlugin
15.4.1.1. DelegatingRequestProcessor
15.4.1.2. DelegatingActionProxy
15.4.2. ActionSupport Classes
15.5. Tapestry
15.5.1. Injecting Spring-managed beans
15.5.1.1. Dependency Injecting Spring Beans into Tapestry pages
15.5.1.2. Component definition files
15.5.1.3. Adding abstract accessors
15.5.1.4. Dependency Injecting Spring Beans into Tapestry pages - Tapestry 4.0+ style
15.6. WebWork
15.7. Further Resources
16. Portlet MVC Framework
16.1. Introduction
16.1.1. Controllers - The C in MVC
16.1.2. Views - The V in MVC
16.1.3. Web-scoped beans
16.2. The DispatcherPortlet
16.3. The ViewRendererServlet
16.4. Controllers
16.4.1. AbstractController and PortletContentGenerator
16.4.2. Other simple controllers
16.4.3. Command Controllers
16.4.4. PortletWrappingController
16.5. Handler mappings
16.5.1. PortletModeHandlerMapping
16.5.2. ParameterHandlerMapping
16.5.3. PortletModeParameterHandlerMapping
16.5.4. Adding HandlerInterceptors
16.5.5. HandlerInterceptorAdapter
16.5.6. ParameterMappingInterceptor
16.6. Views and resolving them
16.7. Multipart (file upload) support
16.7.1. Using the PortletMultipartResolver
16.7.2. Handling a file upload in a form
16.8. Handling exceptions
16.9. Portlet application deployment
IV. Integration
17. Remoting and web services using Spring
17.1. Introduction
17.2. Exposing services using RMI
17.2.1. Exporting the service using the RmiServiceExporter
17.2.2. Linking in the service at the client
17.3. Using Hessian or Burlap to remotely call services via HTTP
17.3.1. Wiring up the DispatcherServlet for Hessian
17.3.2. Exposing your beans by using the HessianServiceExporter
17.3.3. Linking in the service on the client
17.3.4. Using Burlap
17.3.5. Applying HTTP basic authentication to a service exposed through Hessian or Burlap
17.4. Exposing services using HTTP invokers
17.4.1. Exposing the service object
17.4.2. Linking in the service at the client
17.5. Web services
17.5.1. Exposing services using JAX-RPC
17.5.2. Accessing web services
17.5.3. Register Bean Mappings
17.5.4. Registering our own Handler
17.5.5. Exposing web services using XFire
17.6. JMS
17.6.1. Server-side configuration
17.6.2. Client-side configuration
17.7. Auto-detection is not implemented for remote interfaces
17.8. Considerations when choosing a technology
18. Enterprise Java Bean (EJB) integration
18.1. Introduction
18.2. Accessing EJBs
18.2.1. Concepts
18.2.2. Accessing local SLSBs
18.2.3. Accessing remote SLSBs
18.3. Using Spring's convenience EJB implementation classes
19. JMS
19.1. Introduction
19.2. Using Spring JMS
19.2.1. JmsTemplate
19.2.2. Connections
19.2.3. Destination Management
19.2.4. Message Listener Containers
19.2.4.1. SimpleMessageListenerContainer
19.2.4.2. DefaultMessageListenerContainer
19.2.4.3. ServerSessionMessageListenerContainer
19.2.5. Transaction management
19.3. Sending a Message
19.3.1. Using Message Converters
19.3.2. SessionCallback and ProducerCallback
19.4. Receiving a message
19.4.1. Synchronous Reception
19.4.2. Asynchronous Reception - Message-Driven POJOs
19.4.3. The SessionAwareMessageListener interface
19.4.4. The MessageListenerAdapter
19.4.5. Participating in transactions
20. JMX
20.1. Introduction
20.2. Exporting your beans to JMX
20.2.1. Creating an MBeanServer
20.2.2. Reusing an existing MBeanServer
20.2.3. Lazy-initialized MBeans
20.2.4. Automatic registration of MBeans
20.2.5. Controlling the registration behavior
20.3. Controlling the management interface of your beans
20.3.1. The MBeanInfoAssembler Interface
20.3.2. Using source-Level metadata
20.3.3. Using JDK 5.0 Annotations
20.3.4. Source-Level Metadata Types
20.3.5. The AutodetectCapableMBeanInfoAssembler interface
20.3.6. Defining Management interfaces using Java interfaces
20.3.7. Using MethodNameBasedMBeanInfoAssembler
20.4. Controlling the ObjectNames for your beans
20.4.1. Reading ObjectNames from Properties
20.4.2. Using the MetadataNamingStrategy
20.5. JSR-160 Connectors
20.5.1. Server-side Connectors
20.5.2. Client-side Connectors
20.5.3. JMX over Burlap/Hessian/SOAP
20.6. Accessing MBeans via Proxies
20.7. Notifications
20.7.1. Registering Listeners for Notifications
20.7.2. Publishing Notifications
20.8. Further Resources
21. JCA CCI
21.1. Introduction
21.2. Configuring CCI
21.2.1. Connector configuration
21.2.2. ConnectionFactory configuration in Spring
21.2.3. Configuring CCI connections
21.2.4. Using a single CCI connection
21.3. Using Spring's CCI access support
21.3.1. Record conversion
21.3.2. The CciTemplate
21.3.3. DAO support
21.3.4. Automatic output record generation
21.3.5. Summary
21.3.6. Using a CCI Connection and Interaction directly
21.3.7. Example for CciTemplate usage
21.4. Modeling CCI access as operation objects
21.4.1. MappingRecordOperation
21.4.2. MappingCommAreaOperation
21.4.3. Automatic output record generation
21.4.4. Summary
21.4.5. Example for MappingRecordOperation usage
21.4.6. Example for MappingCommAreaOperation usage
21.5. Transactions
22. Email
22.1. Introduction
22.2. Usage
22.2.1. Basic MailSender and SimpleMailMessage usage
22.2.2. Using the JavaMailSender and the MimeMessagePreparator
22.3. Using the JavaMail MimeMessageHelper
22.3.1. Sending attachments and inline resources
22.3.1.1. Attachments
22.3.1.2. Inline resources
22.3.2. Creating email content using a templating library
22.3.2.1. A Velocity-based example
23. Scheduling and Thread Pooling
23.1. Introduction
23.2. Using the OpenSymphony Quartz Scheduler
23.2.1. Using the JobDetailBean
23.2.2. Using the MethodInvokingJobDetailFactoryBean
23.2.3. Wiring up jobs using triggers and the SchedulerFactoryBean
23.3. Using JDK Timer support
23.3.1. Creating custom timers
23.3.2. Using the MethodInvokingTimerTaskFactoryBean
23.3.3. Wrapping up: setting up the tasks using the TimerFactoryBean
23.4. The Spring TaskExecutor abstraction
23.4.1. TaskExecutor types
23.4.2. Using a TaskExecutor
24. Dynamic language support
24.1. Introduction
24.2. A first example
24.3. Defining beans that are backed by dynamic languages
24.3.1. Common concepts
24.3.1.1. The <lang:language/> element
24.3.1.2. Refreshable beans
24.3.1.3. Inline dynamic language source files
24.3.1.4. Understanding Constructor Injection in the context of dynamic-language-backed beans
24.3.2. JRuby beans
24.3.3. Groovy beans
24.3.3.1. Customising Groovy objects via a callback
24.3.4. BeanShell beans
24.4. Scenarios
24.4.1. Scripted Spring MVC Controllers
24.4.2. Scripted Validators
24.5. Bits and bobs
24.5.1. AOP - advising scripted beans
24.5.2. Scoping
24.6. Further Resources
25. Annotations and Source Level Metadata Support
25.1. Introduction
25.2. Spring's metadata support
25.3. Annotations
25.3.1. @Required
25.3.2. Other @Annotations in Spring
25.4. Integration with Jakarta Commons Attributes
25.5. Metadata and Spring AOP autoproxying
25.5.1. Fundamentals
25.5.2. Declarative transaction management
25.5.3. Pooling
25.5.4. Custom metadata
25.6. Using attributes to minimize MVC web tier configuration
V. Sample applications
26. Showcase applications
26.1. Introduction
26.2. Spring MVC Controllers implemented in a dynamic language
26.2.1. Build and deployment
26.3. Implementing DAOs using SimpleJdbcTemplate and @Repository
26.3.1. The domain
26.3.2. The data access objects
26.3.3. Build
A. XML Schema-based configuration
A.1. Introduction
A.2. XML Schema-based configuration
A.2.1. Referencing the schemas
A.2.2. The util schema
A.2.2.1. <util:constant/>
A.2.2.2. <util:property-path/>
A.2.2.3. <util:properties/>
A.2.2.4. <util:list/>
A.2.2.5. <util:map/>
A.2.2.6. <util:set/>
A.2.3. The jee schema
A.2.3.1. <jee:jndi-lookup/> (simple)
A.2.3.2. <jee:jndi-lookup/> (with single JNDI environment setting)
A.2.3.3. <jee:jndi-lookup/> (with multiple JNDI environment settings)
A.2.3.4. <jee:jndi-lookup/> (complex)
A.2.3.5. <jee:local-slsb/> (simple)
A.2.3.6. <jee:local-slsb/> (complex)
A.2.3.7. <jee:remote-slsb/>
A.2.4. The lang schema
A.2.5. The tx (transaction) schema
A.2.6. The aop schema
A.2.7. The tool schema
A.2.8. The beans schema
A.3. Setting up your IDE
A.3.1. Setting up Eclipse
A.3.2. Setting up IntelliJ IDEA
A.3.3. Integration issues
A.3.3.1. XML parsing errors in the Resin v.3 application server
B. Extensible XML authoring
B.1. Introduction
B.2. Authoring the schema
B.3. Coding a NamespaceHandler
B.4. Coding a BeanDefinitionParser
B.5. Registering the handler and the schema
B.5.1. 'META-INF/spring.handlers'
B.5.2. 'META-INF/spring.schemas'
B.6. Using a custom extension in your Spring XML configuration
B.7. Meatier examples
B.7.1. Nesting custom tags within custom tags
B.7.2. Custom attributes on 'normal' elements
B.8. Further Resources
C. spring-beans-2.0.dtd
D. spring.tld
D.1. Introduction
D.2. The bind tag
D.3. The escapeBody tag
D.4. The hasBindErrors tag
D.5. The htmlEscape tag
D.6. The message tag
D.7. The nestedPath tag
D.8. The theme tag
D.9. The transform tag
E. spring-form.tld
E.1. Introduction
E.2. The checkbox tag
E.3. The errors tag
E.4. The form tag
E.5. The hidden tag
E.6. The input tag
E.7. The label tag
E.8. The option tag
E.9. The options tag
E.10. The password tag
E.11. The radiobutton tag
E.12. The select tag
E.13. The textarea tag

Preface

Developing software applications is hard enough even with good tools and technologies. Implementing applications using platforms which promise everything but turn out to be heavy-weight, hard to control and not very efficient during the development cycle makes it even harder. Spring provides a light-weight solution for building enterprise-ready applications, while still supporting the possibility of using declarative transaction management, remote access to your logic using RMI or web services, and various options for persisting your data to a database. Spring provides a full-featured MVC framework, and transparent ways of integrating AOP into your software.

Spring could potentially be a one-stop-shop for all your enterprise applications; however, Spring is modular, allowing you to use just those parts of it that you need, without having to bring in the rest. You can use the IoC container, with Struts on top, but you could also choose to use just the Hibernate integration code or the JDBC abstraction layer. Spring has been (and continues to be) designed to be non-intrusive, meaning dependencies on the framework itself are generally none (or absolutely minimal, depending on the area of use).

This document provides a reference guide to Spring's features. Since this document is still to be considered very much work-in-progress, if you have any requests or comments, please post them on the user mailing list or on the support forums at http://forum.springframework.org/.

Before we go on, a few words of gratitude are due to Christian Bauer (of the Hibernate team), who prepared and adapted the DocBook-XSL software in order to be able to create Hibernate's reference guide, thus also allowing us to create this one. Also thanks to Russell Healy for doing an extensive and valuable review of some of the material.

Chapter 1. Introduction

Background

In early 2004, Martin Fowler asked the readers of his site: when talking about Inversion of Control: “the question is, what aspect of control are [they] inverting?”. Fowler then suggested renaming the principle (or at least giving it a more self-explanatory name), and started to use the term Dependency Injection. His article then continued to explain the ideas underpinning the Inversion of Control (IoC) and Dependency Injection (DI) principle.

If you need a decent insight into IoC and DI, please do refer to said article : http://martinfowler.com/articles/injection.html.

Java applications (a loose term which runs the gamut from constrained applets to full-fledged n-tier server-side enterprise applications) typically are composed of a number of objects that collaborate with one another to form the application proper. The objects in an application can thus be said to have dependencies between themselves.

The Java language and platform provides a wealth of functionality for architecting and building applications, ranging all the way from the very basic building blocks of primitive types and classes (and the means to define new classes), to rich full-featured application servers and web frameworks. One area that is decidedly conspicuous by its absence is any means of taking the basic building blocks and composing them into a coherent whole; this area has typically been left to the purvey of the architects and developers tasked with building an application (or applications). Now to be fair, there are a number of design patterns devoted to the business of composing the various classes and object instances that makeup an all-singing, all-dancing application. Design patterns such as Factory, Abstract Factory, Builder, Decorator, and Service Locator (to name but a few) have widespread recognition and acceptance within the software development industry (presumably that is why these patterns have been formalized as patterns in the first place). This is all very well, but these patterns are just that: best practices given a name, typically together with a description of what the pattern does, where the pattern is typically best applied, the problems that the application of the pattern addresses, and so forth. Notice that the last paragraph used the phrase “... a description of what the pattern does...”; pattern books and wikis are typically listings of such formalized best practice that you can certainly take away, mull over, and then implement yourself in your application.

The IoC component of the Spring Framework addresses the enterprise concern of taking the classes, objects, and services that are to compose an application, by providing a formalized means of composing these various disparate components into a fully working application ready for use. The Spring Framework takes best practices that have been proven over the years in numerous applications and formalized as design patterns, and actually codifies these patterns as first class objects that you as an architect and developer can take away and integrate into your own application(s). This is a Very Good Thing Indeed as attested to by the numerous organizations and institutions that have used the Spring Framework to engineer robust, maintainable applications.

1.1. Overview

The Spring Framework contains a lot of features, which are well-organized in seven modules shown in the diagram below. This chapter discusses each of the modules in turn.

Overview of the Spring Framework

The Core package is the most fundamental part of the framework and provides the IoC and Dependency Injection features. The basic concept here is the BeanFactory, which provides a sophisticated implementation of the factory pattern which removes the need for programmatic singletons and allows you to decouple the configuration and specification of dependencies from your actual program logic.

The Context package build on the solid base provided by the Core package: it provides a way to access objects in a framework-style manner in a fashion somewhat reminiscent of a JNDI-registry. The context package inherits its features from the beans package and adds support for internationalization (I18N) (using for example resource bundles), event-propagation, resource-loading, and the transparent creation of contexts by, for example, a servlet container.

The DAO package provides a JDBC-abstraction layer that removes the need to do tedious JDBC coding and parsing of database-vendor specific error codes. Also, the JDBC package provides a way to do programmatic as well as declarative transaction management, not only for classes implementing special interfaces, but for all your POJOs (plain old Java objects).

The ORM package provides integration layers for popular object-relational mapping APIs, including JPA, JDO, Hibernate, and iBatis. Using the ORM package you can use all those O/R-mappers in combination with all the other features Spring offers, such as the simple declarative transaction management feature mentioned previously.

Spring's AOP package provides an AOP Alliance-compliant aspect-oriented programming implementation allowing you to define, for example, method-interceptors and pointcuts to cleanly decouple code implementing functionality that should logically speaking be separated. Using source-level metadata functionality you can also incorporate all kinds of behavioral information into your code, in a manner similar to that of .NET attributes.

Spring's Web package provides basic web-oriented integration features, such as multipart file-upload functionality, the initialization of the IoC container using servlet listeners and a web-oriented application context. When using Spring together with WebWork or Struts, this is the package to integrate with.

Spring's MVC package provides a Model-View-Controller (MVC) implementation for web-applications. Spring's MVC framework is not just any old implementation; it provides a clean separation between domain model code and web forms, and allows you to use all the other features of the Spring Framework.

1.2. Usage scenarios

With the building blocks described above you can use Spring in all sorts of scenarios, from applets up to fully-fledged enterprise applications using Spring's transaction management functionality and web framework integration.

Typical full-fledged Spring web application

By using Spring's declarative transaction management features the web application is fully transactional, just as it would be when using container managed transactions as provided by Enterprise JavaBeans. All your custom business logic can be implemented using simple POJOs, managed by Spring's IoC container. Additional services include support for sending email, and validation that is independent of the web layer enabling you to choose where to execute validation rules. Spring's ORM support is integrated with JPA, Hibernate, JDO and iBatis; for example, when using Hibernate, you can continue to use your existing mapping files and standard Hibernate SessionFactory configuration. Form controllers seamlessly integrate the web-layer with the domain model, removing the need for ActionForms or other classes that transform HTTP parameters to values for your domain model.

Spring middle-tier using a third-party web framework

Sometimes the current circumstances do not allow you to completely switch to a different framework. The Spring Framework does not force you to use everything within it; it is not an all-or-nothing solution. Existing front-ends built using WebWork, Struts, Tapestry, or other UI frameworks can be integrated perfectly well with a Spring-based middle-tier, allowing you to use the transaction features that Spring offers. The only thing you need to do is wire up your business logic using an ApplicationContext and integrate your web layer using a WebApplicationContext.

Remoting usage scenario

When you need to access existing code via web services, you can use Spring's Hessian-, Burlap-, Rmi- or JaxRpcProxyFactory classes. Enabling remote access to existing applications suddenly is not that hard anymore.

EJBs - Wrapping existing POJOs

The Spring Framework also provides an access- and abstraction- layer for Enterprise JavaBeans, enabling you to reuse your existing POJOs and wrap them in Stateless Session Beans, for use in scalable, failsafe web applications that might need declarative security.

Chapter 2. What's new in Spring 2.0?

2.1. Introduction

If you have been using the Spring Framework for some time, you will be aware that Spring has just undergone a major revision.

JDK Support

The Spring Framework continues to be totally compatible with all versions of Java since (and including) Java 1.3. This means that 1.3, 1.4, and 1.5 are supported, although some advanced functionality of the Spring Framework may not be available to you if you are (for example) committed to using Java 1.3.

This revision includes a host of new features, and a lot of the existing functionality has been reviewed and improved. In fact, so much of Spring is shiny and improved that the Spring development team decided that the next release of Spring merited an increment of the version number; and so Spring 2.0 was announced in December 2005 at the Spring Experience conference in Florida.

This chapter is a guide to the new and improved features of Spring 2.0. It is intended to provide a high-level summary so that seasoned Spring architects and developers can become immediately familiar with the new Spring 2.0 functionality. For more in-depth information on the features, please refer to the corresponding sections hyperlinked from within this chapter.

Some of the new and improved functionality described below has been (or will be) backported into the Spring 1.2.x release line. Please do consult the changelogs for the 1.2.x releases to see if a feature has been backported.

2.2. The Inversion of Control (IoC) container

One of the areas that contains a considerable number of 2.0 improvements is Spring's IoC container.

2.2.1. Easier XML configuration

Spring XML configuration is now even easier, thanks to the advent of the new XML configuration syntax based on XML Schema. If you want to take advantage of the new tags that Spring provides (and the Spring team certainly suggest that you do because they make configuration less verbose and easier to read), then do read the section entitled Appendix A, XML Schema-based configuration.

On a related note, there is a new, updated DTD for Spring 2.0 that you may wish to reference if you cannot take advantage of the XML Schema-based configuration. The DOCTYPE declaration is included below for your convenience, but the interested reader should definitely read the 'spring-beans-2.0.dtd' DTD included in the 'dist/resources' directory of the Spring 2.0 distribution.

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN"
		  "http://www.springframework.org/dtd/spring-beans-2.0.dtd">

2.2.2. New bean scopes

Previous versions of Spring had IoC container level support for exactly two distinct bean scopes (singleton and prototype). Spring 2.0 improves on this by not only providing a number of additional scopes depending on the environment in which Spring is being deployed (for example, request and session scoped beans in a web environment), but also by providing integration points so that Spring users can create their own scopes.

It should be noted that although the underlying (and internal) implementation for singleton- and prototype-scoped beans has been changed, this change is totally transparent to the end user... no existing configuration needs to change, and no existing configuration will break.

Both the new and the original scopes are detailed in the section entitled Section 3.4, “Bean scopes”.

2.2.3. Extensible XML authoring

Not only is XML configuration easier to write, it is now also extensible.

What 'extensible' means in this context is that you, as an application developer, or (more likely) as a third party framework or product vendor, can write custom tags that other developers can then plug into their own Spring configuration files. This allows you to have your own domain specific language (the term is used loosely here) of sorts be reflected in the specific configuration of your own components.

Implementing custom Spring tags may not be of interest to every single application developer or enterprise architect using Spring in their own projects. We expect third-party vendors to be highly interested in developing custom configuration tags for use in Spring configuration files.

The extensible configuration mechanism is documented in Appendix B, Extensible XML authoring.

2.3. Aspect Oriented Programming (AOP)

Spring 2.0 has a much improved AOP offering. The Spring AOP framework itself is markedly easier to configure in XML, and significantly less verbose as a result; and Spring 2.0 integrates with the AspectJ pointcut language and @AspectJ aspect declaration style. The chapter entitled Chapter 6, Aspect Oriented Programming with Spring is dedicated to describing this new support.

2.3.1. Easier AOP XML configuration

Spring 2.0 introduces new schema support for defining aspects backed by regular Java objects. This support takes advantage of the AspectJ pointcut language and offers fully typed advice (i.e. no more casting and Object[] argument manipulation). Details of this support can be found in the section entitled Section 6.3, “Schema-based AOP support”.

2.3.2. Support for @AspectJ aspects

Spring 2.0 also supports aspects defined using the @AspectJ annotations. These aspects can be shared between AspectJ and Spring AOP, and require (honestly!) only some simple configuration. Said support for @AspectJ aspects is discussed in Section 6.2, “@AspectJ support”.

2.4. The Middle Tier

2.4.1. Easier configuration of declarative transactions in XML

The way that transactions are configured in Spring 2.0 has been changed significantly. The previous 1.2.x style of configuration continues to be valid (and supported), but the new style is markedly less verbose and is the recommended style. Spring 2.0 also ships with an AspectJ aspects library that you can use to make pretty much any object transactional - even objects not created by the Spring IoC container.

The chapter entitled Chapter 9, Transaction management contains all of the details.

2.4.2. JPA

Spring 2.0 ships with a JPA abstraction layer that is similar in intent to Spring's JDBC abstraction layer in terms of scope and general usage patterns.

If you are interested in using a JPA-implementation as the backbone of your persistence layer, the section entitled Section 12.6, “JPA” is dedicated to detailing Spring's support and value-add in this area.

2.4.3. Asynchronous JMS

Prior to Spring 2.0, Spring's JMS offering was limited to sending messages and the synchronous receiving of messages. This functionality (encapsulated in the JmsTemplate class) is great, but it doesn't address the requirement for the asynchronous receiving of messages.

Spring 2.0 now ships with full support for the reception of messages in an asynchronous fashion, as detailed in the section entitled Section 19.4.2, “Asynchronous Reception - Message-Driven POJOs”.

2.4.4. JDBC

There are some small (but nevertheless notable) new classes in the Spring Framework's JDBC support library. The first, NamedParameterJdbcTemplate, provides support for programming JDBC statements using named parameters (as opposed to programming JDBC statements using only classic placeholder ('?') arguments.

Another of the new classes, the SimpleJdbcTemplate, is aimed at making using the JdbcTemplate even easier to use when you are developing against Java 5+ (Tiger).

2.5. The Web Tier

The web tier support has been substantially improved and expanded in Spring 2.0.

2.5.1. A form tag library for Spring MVC

A rich JSP tag library for Spring MVC was the JIRA issue that garnered the most votes from Spring users (by a wide margin).

Spring 2.0 ships with a full featured JSP tag library that makes the job of authoring JSP pages much easier when using Spring MVC; the Spring team is confident it will satisfy all of those developers who voted for the issue on JIRA. The new tag library is itself covered in the section entitled Section 13.9, “Using Spring's form tag library”, and a quick reference to all of the new tags can be found in the appendix entitled Appendix E, spring-form.tld.

2.5.2. Sensible defaulting in Spring MVC

For a lot of projects, sticking to established conventions and having reasonable defaults is just what the projects need... this theme of convention-over-configuration now has explicit support in Spring MVC. What this means is that if you establish a set of naming conventions for your Controllers and views, you can substantially cut down on the amount of XML configuration that is required to setup handler mappings, view resolvers, ModelAndView instances, etc. This is a great boon with regards to rapid prototyping, and can also lend a degree of (always good-to-have) consistency across a codebase.

Spring MVC's convention-over-configuration support is detailed in the section entitled Section 13.11, “Convention over configuration”

2.5.3. Portlet framework

Spring 2.0 ships with a Portlet framework that is conceptually similar to the Spring MVC framework. Detailed coverage of the Spring Portlet framework can be found in the section entitled Chapter 16, Portlet MVC Framework.

2.6. Everything else

This final section outlines all of the other new and improved Spring 2.0 features and functionality.

2.6.1. Dynamic language support

Spring 2.0 now has support for beans written in languages other than Java, with the currently supported dynamic languages being JRuby, Groovy and BeanShell. This dynamic language support is comprehensively detailed in the section entitled Chapter 24, Dynamic language support.

2.6.2. JMX

The Spring Framework now has support for Notifications; it is also possible to exercise declarative control over the registration behavior of MBeans with an MBeanServer.

2.6.3. Task scheduling

Spring 2.0 offers an abstraction around the scheduling of tasks. For the interested developer, the section entitled Section 23.4, “The Spring TaskExecutor abstraction” contains all of the details.

2.6.4. Java 5 (Tiger) support

Find below pointers to documentation describing some of the new Java 5 support in Spring 2.0.