spring framework 2.0.6

• Introduction support
• A Pointcut abstraction, supporting "static" pointcuts (class and method-based) and "dynamic" pointcuts (also considering method arguments). There are currently no AOP Alliance interfaces for pointcuts.
• A full range of advice types, including around, before, after returning and throws advice.
• Extensibility allowing arbitrary custom advice types to be plugged in without modifying the core framework.

Note that use of this package does not require the use of the ajc compiler or AspectJ load-time weaver. It is intended to enable the use of a valuable subset of AspectJ functionality, with consistent semantics, with the proxy-based Spring AOP framework.

Normally to be used through an AspectJAutoProxyCreator rather than directly.

Spring AOP supports proxying interfaces or classes, introductions, and offers static and dynamic pointcuts.

Any Spring AOP proxy can be cast to the ProxyConfig AOP configuration interface in this package to add or remove interceptors.

The ProxyFactoryBean is a convenient way to create AOP proxies in a BeanFactory or ApplicationContext. However, proxies can be created programmatically using the ProxyFactory class.

The various post-processors in this package need only be added to an ApplicationContext (typically in an XML bean definition document) to automatically proxy selected beans.

NB: Automatic auto-proxying is not supported for BeanFactory implementations, as post-processors beans are only automatically detected in application contexts. Post-processors can be explicitly registered on a ConfigurableBeanFactory instead.

A BeanWrapper object may be used to set and get bean properties, singly or in bulk.

The classes in this package are discussed in Chapter 11 of Expert One-On-One J2EE Design and Development by Rod Johnson (Wrox, 2002).

Provides an alternative to the Singleton and Prototype design patterns, including a consistent approach to configuration management. Builds on the org.springframework.beans package.

This package and related packages are discussed in Chapter 11 of Expert One-On-One J2EE Design and Development by Rod Johnson (Wrox, 2002).

Note: This package is only relevant for special sharing of bean factories, for example behind EJB facades. It is not used in a typical web application or standalone application.

Some of these editors are registered automatically by BeanWrapperImpl. "CustomXxxEditor" classes are intended for manual registration in specific binding processes, as they are localized or the like.

There is no necessity for Spring applications to depend on ApplicationContext or even BeanFactory functionality explicitly. One of the strengths of the Spring architecture is that application objects can often be configured without any dependency on Spring-specific APIs.

Note: This package is only relevant for special sharing of application contexts, for example behind EJB facades. It is not used in a typical web application or standalone application.

All these exceptions are unchecked, meaning that calling code can leave them uncaught and treat all data access exceptions as fatal.

The classes in this package are discussed in Chapter 9 of Expert One-On-One J2EE Design and Development by Rod Johnson (Wrox, 2002).

The motivation for the classes in this package are discussed in Chapter 11 of Expert One-On-One J2EE Design and Development by Rod Johnson (Wrox, 2002).

However, the implementation and naming of classes in this package has changed. It now uses FactoryBeans and AOP, rather than the custom bean definitions described in Expert One-on-One J2EE.

In this model, the EJB is a facade, with as many POJO helpers behind the BeanFactory as required.

The classes in this package are discussed in Chapter 11 of Expert One-On-One J2EE Design and Development by Rod Johnson (Wrox, 2002). The present version has changed somewhat, but has the same goals.

Note that the default behavior is to look for an EJB enviroment variable with name ejb/BeanFactoryPath that specifies the location on the classpath of an XML bean factory definition file (such as /com/mycom/mypackage/mybeans.xml). If this JNDI key is missing, your EJB subclass won't successfully initialize in the container.

• Simplify error handling, avoiding the need for try/catch/final blocks in application code.
• Present exceptions to application code in a generic hierarchy of unchecked exceptions, enabling applications to catch data access exceptions without being dependent on JDBC, and to ignore fatal exceptions there is no value in catching.
• Allow the implementation of error handling to be modified to target different RDBMSes without introducing proprietary dependencies into application code.

This package and related packages are discussed in Chapter 9 of Expert One-On-One J2EE Design and Development by Rod Johnson (Wrox, 2002).

NamedParameterJdbcTemplate is a wrapper around JdbcTemplate that adds support for named parameter parsing. It does not implement the JdbcOperations interface or extend JdbcTemplate, but implements the dedicated NamedParameterJdbcOperations interface.

If you need the full power of Spring JDBC for less common operations, use the getJdbcOperations() method of NamedParameterJdbcTemplate and work with the returned classic template, or use a JdbcTemplate instance directly.

SimpleJdbcTemplate is a wrapper around JdbcTemplate that takes advantage of varargs and autoboxing. It also offers only a subset of the methods available on JdbcTemplate: Hence, it does not implement the JdbcOperations interface or extend JdbcTemplate, but implements the dedicated SimpleJdbcOperations interface.

If you need the full power of Spring JDBC for less common operations, use the getJdbcOperations() method of SimpleJdbcTemplate and work with the returned classic template, or use a JdbcTemplate instance directly.

This higher level of JDBC abstraction depends on the lower-level abstraction in the org.springframework.jdbc.core package. Exceptions thrown are as in the org.springframework.dao package, meaning that code using this package does not need to implement JDBC or RDBMS-specific error handling.

This package and related packages are discussed in Chapter 9 of Expert One-On-One J2EE Design and Development by Rod Johnson (Wrox, 2002).

Can be used independently, for example in custom JDBC access code, or in JDBC-based O/R mapping layers.

Can be used independently, for example in custom JDBC access code.

Can be used independently from jdbc.core and jdbc.object, for example in custom JDBC access code.

Can be used independently, for example in custom JDBC access code.

Allows the target service to be load-balanced across a number of queue receivers, and provides a level of indirection between the client and the service: They only need to agree on a queue name and a service interface.

The classes in this package are discussed in Chapter 11 of Expert One-On-One J2EE Design and Development by Rod Johnson (Wrox, 2002).

Useful for setting up a simple JNDI environment for test suites or standalone applications. If e.g. JDBC DataSources get bound to the same JNDI names as within a J2EE container, both application code and configuration can me reused without changes.

More convenient to use than dynamic mock objects (EasyMock) or existing Servlet API mock objects (MockObjects).

More convenient to use than dynamic mock objects (EasyMock) or existing Portlet API mock objects.

Contains SessionFactory helper classes, a template plus callback for Hibernate access, and an implementation of Spring's transaction SPI for local Hibernate transactions.

This package supports Hibernate 2.1 only. See the org.springframework.orm.hibernate3 package for Hibernate 3.x support.

Contains SessionFactory helper classes, a template plus callback for Hibernate access, and an implementation of Spring's transaction SPI for local Hibernate transactions.

This package supports Hibernate 3.x only. See the org.springframework.orm.hibernate package for Hibernate 2.1 support.

Contains resource helper classes and template classes for data access with the iBATIS SqlMapClient API.

Contains SessionFactory helper classes, a template plus callback for TopLink access, and an implementation of Spring's transaction SPI for local TopLink transactions.

Hessian is a slim, binary RPC protocol over HTTP. For information on Hessian, see the Hessian website

Burlap is a slim, XML-based RPC protocol over HTTP. For information on Burlap, see the Burlap website

HTTP invoker is the recommended protocol for Java-to-Java remoting. It is more powerful and more extensible than Hessian and Burlap, at the expense of being tied to Java. Neverthelesss, it is as easy to set up as Hessian and Burlap, which is its main advantage compared to RMI.

Intended for use by tools and aspects (making an ideal target for pointcuts).

The superclasses in this package are ideal for integration testing. Unit testing should not normally involve the Spring container, but should test classes in isolation.

The TransactionFactoryProxyBean can be used to create transactional AOP proxies transparently to code that uses them.

The TransactionInterceptor is the AOP Alliance MethodInterceptor that delivers transactional advice, based on the Spring transaction abstraction. This allows declarative transaction management in any environment, even without JTA if an application uses only a single database.

• If no UiApplicationContextUtils.THEME_SOURCE_BEAN_NAME bean is available in the context or parent context, a default ResourceBundleThemeSource will be created for requested themes. In this case, the base name of the property file will match with the theme name.
• If the bean is available in the context or parent context, a basenamePrefix can be set before the theme name for locating the property files like this:
  <bean id="themeSource" class="org.springframework.ui.context.support.ResourceBundleThemeSource">
<property name="basenamePrefix"><value>theme.</value></property>
</bean>
  in this case, the themes resource bundles will be named theme.<theme_name>XXX.properties.
• This can be defined at application level and/or at servlet level for web applications.
• Normal i18n features of Resource Bundles are available. So a theme message can be dependant of both theme and locale.
• If messages in the resource bundles are in fact paths to resources(css, images, ...), make sure these resources are directly available for the user and not, for example, under the WEB-INF directory.

Supports easy access to beans in the Spring root WebApplicationContext from JSF EL expressions, for example in property values of JSF-managed beans.

Standard controller implementations for the portlet MVC framework that comes with Spring. Provides both abstract base classes and concrete implementations for often seen use cases.

A Controller - as defined in this package - is analogous to a Struts Action. Usually Controllers are JavaBeans to allow easy configuration using the {@link org.springframework.beans org.springframework.beans} package. Controllers define the C from so-called MVC paradigm and can be used in conjunction with the {@link org.springframework.web.portlet.ModelAndView ModelAndView} to achieve interactive applications. The view might be represented by a HTML interface, but, because of model and the controller being completely independent of the view, PDF views are possible, as well as for instance Excel views.

Especially useful to read, while getting into the Spring MVC framework are the following:

• Controller
• BaseCommandController
• ParameterizableViewController

This package and related packages are discussed in Chapters 12 and 13 of Expert One-On-One J2EE Design and Development by Rod Johnson (Wrox, 2002).

To use this feature, using the Commons Attributes implementation, perform the following steps:

1. Invoke the Commons Attributes compiler on your application classes. The classes must be compiled into a Jar rather than the WEB-INF/classes directory.
2. Run the Commons Attributes attribute indexer tool on the Jar containing your controllers.
3. Use Commons Attributes syntax to define a PathMap attribute for each Controller you want mapped.
4. Define a bean of type UrlHandlerMapping in your servletName-servlet.xml bean definition file in your web application. No parameters are required.

You can also use other HandlerMappings, such as BeanNameHandlerMapping, in the same servlet XML file.

Standard controller implementations for the servlet MVC framework that comes with Spring. Provides both abstract base classes and concrete implementations for often seen use cases.

A Controller - as defined in this package - is analogous to a Struts Action. Usually Controllers are JavaBeans to allow easy configuration using the {@link org.springframework.beans org.springframework.beans} package. Controllers define the C from so-called MVC paradigm and can be used in conjunction with the {@link org.springframework.web.servlet.ModelAndView ModelAndView} to achieve interactive applications. The view might be represented by a HTML interface, but, because of model and the controller being completely independent of the view, PDF views are possible, as well as for instance Excel views.

How to actually set up a (web)application using the MVC framework Spring provides is explained in more detail in the MVC-Step-by-Step tutorial, also provided in this package (or have a look here for an online version). The classes contained by this package explain in more detail the actual workflow of some of the abstract and concrete controller and how to extend and fully use their functionality.

Especially useful to read, while getting into the Spring MVC framework are the following:

• Controller
• BaseCommandController
• ParameterizableViewController

Typically a controller that handles multiple request types will extend MultiActionController, and implement multiple request handling methods that will be invoked by reflection if they follow this class' naming convention. Classes are analyzed at startup and methods cached, so the performance overhead of reflection in this approach is negligible.

This approach is analogous to the Struts 1.1 DispatcherAction class, but more sophisticated, as it supports configurable mapping from requests to URLs and allows for delegation as well as subclassing.

This package is discussed in Chapter 12 of Expert One-On-One J2EE Design and Development by Rod Johnson, and used in the sample application.

• If you don't provide a bean of one of these classes as themeResolver, a FixedThemeResolver will be provided with the default theme name 'theme'.
• If you use a defined FixedThemeResolver, you will able to use another theme name for default, but the users will stick on this theme.
• With a CookieThemeResolver or SessionThemeResolver, you can allow the user to change his current theme.
• Generally, you will put in the themes resource bundles the paths of CSS files, images and HTML constructs.
• For retrieving themes data, you can either use the spring:theme tag in JSP or access via the RequestContext for other view technologies.
• The pagedlist demo application uses themes

Application developers don't usually need to implement views, as the framework provides standard views for JSPs, Velocity, XSLT, etc. However, the ability to implement custom views easily by subclassing the AbstractView class in this package can be very helpful if an application has unusual view requirements.

Supports easy access to the Spring root WebApplicationContext from Struts Actions via the ActionSupport and DispatchActionSupport classes. Actions have full access to Spring's WebApplicationContext facilities in this case, and explicitly look up Spring-managed beans.

Also supports wiring Struts Actions as Spring-managed beans in a ContextLoaderPlugIn context, passing middle tier references to them via bean references, using the Action path as bean name. There are two ways to make Struts delegate Action lookup to the ContextLoaderPlugIn:

• Use DelegationActionProxy as Action "type" in struts-config. There's no further setup necessary; you can choose any RequestProcessor. Each such proxy will automatically delegate to the corresponding Spring-managed Action bean in the ContextLoaderPlugIn context.
• Configure DelegatingRequestProcessor as "processorClass" in struts-config, using the original Action "type" (possibly generated by XDoclet) or no "type" at all. To also use Tiles, configure DelegatingTilesRequestProcessor instead.