Spring's approach to AOP is creating "dynamic proxies" to the target objects and "weaving" the
objects with the configured advice to execute the crosscutting logic.
Another popular AOP library is the Eclipse AspectJ project (www.eclipse.org/aspectj), which
provides more powerful features including object construction, class loading, and stronger crosscutting
capability.
However, the good news for Spring and AOP developers is that starting from version 2.0, Spring
provides much tighter integration with AspectJ. The following are some highlights:
Support for AspectJ-style pointcut expressions
·
Support for @AspectJ annotation style, while still using Spring AOP for weaving
·
Support for aspects implemented in AspectJ for DI
·
Support of for load-time weaving within the Spring ApplicationContext
·
Both kinds of AOP have their place, and in most cases, Spring AOP is sufficient in addressing an
application's crosscutting requirements. However, for more complicated requirements, AspectJ can be
used, and both Spring AOP and AspectJ can be mixed in the same Spring-powered application.
AOP has many applications. A typical one given in many of the traditional AOP examples involves
performing some kind of logging, but AOP has found uses well beyond the trivial logging applications.
Indeed, within the Spring Framework itself, AOP is used for many purposes, particularly in transaction
management. Spring AOP is covered in full detail in Chapters 6 and 7, where we show you typical uses of
AOP within the Spring Framework and your own applications, as well as AOP performance and areas
where traditional technologies are better suited than AOP.
Spring Expression Language (SpEL)
Expression Language (EL) is a technology to allow an application to manipulate Java objects at runtime.
However, the problem with EL is that different technologies provide their own EL implementations and
syntaxes. For example, Java Server Pages (JSP) and Java Server Faces (JSF) both have their own EL, and
their syntaxes are different. To solve the problem, the Unified Expression Language (EL) was created.
Because the Spring Framework is evolving so quickly, there is a need for a standard expression
language that can be shared among all the Spring Framework modules as well as other Spring projects.
Consequently, starting in version 3.0, Spring introduced the Spring Expression Language (SpEL). SpEL
provides powerful features for evaluating expressions and for accessing Java objects and Spring beans at
runtime. The result can be used in the application or injected into other JavaBeans.
In this topic, you won't find a chapter dedicated to SpEL. However, throughout the topic, we
will use SpEL where appropriate with detailed explanations.
Validation in Spring
Validation is another large topic in any kind of application. The ideal scenario is that the validation rules
of the attributes within JavaBeans containing business data can be applied in a consistent way,
regardless of whether the data manipulation request is initiated from the frontend, a batch job, or
remotely (e.g., Web Services, RESTful Web Services, RPC, etc.).
Driven by need, the JCP developed the Bean Validation API specification (JSR-303). The Bean
Validation API provides a standard way for defining bean validation rules. For example, when applying
the @NotNull annotation to a bean's property, it means that the attribute shouldn't contain a null value
before being able to persist into the database.
Starting in version 3.0, Spring provides out-of-the-box support for JSR-303. To use the API, just
declare a ValidatorFactoryBean and inject the Validator interface into any Spring-managed beans.
Spring will resolve the underlying implementation for you. By default, Spring will first look for the
Search WWH :
Custom Search
Previous Page
Spring Framework 3 Topic Index
Next Page
Spring Framework 3 Bookmarks
Home