If you're using the Spring IoC container (an Application Context or Bean Factory) for your business objects - and you should be! - you will want to use one of Spring's AOP FactoryBeans.(Remember that a factory bean introduces a layer of indirection, enabling it to create objects of a different type.)
The basic way to create an AOP proxy in Spring is to use the org.spring frame work.aop.frame work.Proxy Factory Bean.This gives complete control over the pointcuts and advice that will apply, and their ordering. However, there are simpler options that are preferable if you don't need such control.
The Proxy Factory Bean, like other Spring Factory Bean implementations, introduces a level of indirection. If you define a Proxy Factory Bean with name foo, what objects referencing foo see is not the Proxy Factory Bean instance itself, but an object created by the Proxy Factory Bean's implementation of the getObject() method. This method will create an AOP proxy wrapping a target object.
One of the most important benefits of using a ProxyFactoryBean or another IoC-aware class to create AOP proxies, is that it means that advices and pointcuts can also be managed by IoC. This is a powerful feature, enabling certain approaches that are hard to achieve with other AOP frameworks. For example, an advice may itself reference application objects (besides the target, which should be available in any AOP framework), benefiting from all the pluggability provided by Dependency Injection.
In common with most FactoryBean implementations provided with Spring, the ProxyFactoryBean class is itself a JavaBean. Its properties are used to:
Some key properties are inherited from org.springframework.aop.framework.ProxyConfig (the superclass for all AOP proxy factories in Spring). These key properties include:
Other properties specific to ProxyFactoryBean include:
Ordering is significant, on a first come-first served basis. That is to say that the first interceptor in the list will be the first to be able to intercept the invocation.
The names are bean names in the current factory, including bean names from ancestor factories.You can't mention bean references here since doing so would result in the ProxyFactoryBean ignoring the singleton setting of the advice.
You can append an interceptor name with an asterisk (*). This will result in the application of all advisor beans with names starting with the part before the asterisk to be applied.
JDK- and CGLIB-based proxies
This serves as the definitive documentation on how the Proxy Factory Bean chooses to create one of either a JDK- and CGLIB-based proxy for a particular target object (that is to be proxied).
If the class of a target object that is to be proxied (hereafter simply referred to as the target class) doesn't implement any interfaces, then a CGLIB-based proxy will be created.This is the easiest scenario, because JDK proxies are interface based, and no interfaces means JDK proxying isn't even possible. One simply plugs in the target bean, and specifies the list of interceptors via the interceptor Names property.
Note that a CGLIB-based proxy will be created even if the proxy Target Class property of the Proxy Factory Bean has been set to false. (Obviously this makes no sense, and is best removed from the bean definition because it is at best redundant, and at worst confusing.)
If the target class implements one (or more) interfaces, then the type of proxy that is created depends on the configuration of the Proxy Factory Bean.
If the proxyTargetClass property of the ProxyFactoryBean has been set to true, then a CGLIB-based proxy will be created.This makes sense, and is in keeping with the principle of least surprise. Even if the proxyInterfaces property of the Proxy Factory Bean has been set to one or more fully qualified interface names, the fact that the proxyTargetClass property is set to true will cause CGLIB-based proxying to be in effect.
If the proxy Inter faces property of the Proxy Factory Bean has been set to one or more fully qualified interface names, then a JDK-based proxy will be created. The created proxy will implement all of the interfaces that were specified in the proxyInterfaces property; if the target class happens to implement a whole lot more interfaces than those specified in the proxy Inter faces property, that is all well and good but those additional interfaces will not be implemented by the returned proxy.
If the proxy Inter faces property of the Proxy Factory Bean has not been set, but the target class does implement one (or more) interfaces, then the Proxy Factory Bean will auto-detect the fact that the target class does actually implement at least one interface, and a JDK-based proxy will be created.The interfaces that are actually proxied will be all of the interfaces that the target class implements; in effect, this is the same as simply supplying a list of each and every interface that the target class implements to the proxyInterfaces property. However, it is significantly less work, and less prone to typos.
Let's look at a simple example of ProxyFactoryBean in action. This example involves:
Note that the interceptorNames property takes a list of String: the bean names of the interceptor or advisors in the current factory. Advisors, interceptors, before, after returning and throws advice objects can be used. The ordering of advisors is significant.
Other beans in the same IoC context can express a strongly typed dependency on it, as with an ordinary Java object:<bean id="personUser" class="com.mycompany.PersonUser">
The PersonUser class in this example would expose a property of type Person. As far as it's concerned, the AOP proxy can be used transparently in place of a "real" person implementation. However, its class would be a dynamic proxy class.It would be possible to cast it to the Advised interface .
It's possible to conceal the distinction between target and proxy using an anonymous inner bean, as follows. Only the ProxyFactoryBean definition is different; the advice is included only for completeness:<bean id="myAdvisor" class="com.mycompany.MyAdvisor">
This has the advantage that there's only one object of type Person: useful if we want to prevent users of the application context from obtaining a reference to the un-advised object, or need to avoid any ambiguity with Spring IoC autowiring.There's also arguably an advantage in that the Proxy Factory Bean definition is self-contained.However, there are times when being able to obtain the un-advised target from the factory might actually be an advantage: for example, in certain test scenarios.
What if you need to proxy a class, rather than one or more interfaces?
Imagine that in our example above, there was no Person interface: we needed to advise a class called Person that didn't implement any business interface. In this case, you can configure Spring to use CGLIB proxying, rather than dynamic proxies.Simply set the proxy Target Class property on the Proxy Factory Bean above to true. While it's best to program to interfaces, rather than classes, the ability to advise classes that don't implement interfaces can be useful when working with legacy code. (In general, Spring isn't prescriptive. While it makes it easy to apply good practices, it avoids forcing a particular approach.)
If you want to, you can force the use of CGLIB in any case, even if you do have interfaces.CGLIB proxying works by generating a subclass of the target class at runtime. Spring configures this generated subclass to delegate method calls to the original target: the subclass is used to implement the Decorator pattern, weaving in the advice.
CGLIB proxying should generally be transparent to users. However, there are some issues to consider:
There's little performance difference between CGLIB proxying and dynamic proxies. As of Spring 1.0,dynamic proxies are slightly faster.However, this may change in the future.Performance should not be a decisive consideration in this case.
Using 'global' advisors
By appending an asterisk to an interceptor name, all advisors with bean names matching the part before the asterisk, will be added to the advisor chain.This can come in handy if you need to add a standard set of 'global' advisors:<bean id="proxy" class="org.springframework.aop.framework.ProxyFactoryBean">
Java-Springs Related Interview Questions
|Adv Java Interview Questions||J2EE Interview Questions|
|Core Java Interview Questions||JSP Interview Questions|
|Java-Springs Interview Questions||Java Servlets Interview Questions|
|JMS(Java Message Service) Interview Questions||Hibernate Interview Questions|
|Java applet Interview Questions||Java Interview Questions|
|Framework7 Interview Questions||Java collections framework Interview Questions|
|Java 8 Interview Questions||Java Programmer Interview Questions|
Introduction To Spring Framework
New Features And Enhancements In Spring 3.0
The Ioc Container
Validation, Data Binding, And Type Conversion
Spring Expression Language (spel)
Aspect Oriented Programming With Spring
Spring Aop Apis
Data Access With Jdbc
Object Relational Mapping (orm) Data Access
Marshalling Xml Using O/x Mappers
Web Mvc Framework
Integrating With Other Web Frameworks
Portlet Mvc Framework
Remoting And Web Services Using Spring
Enterprise Javabeans (ejb) Integration
Jms (java Message Service)
Task Execution And Scheduling
Dynamic Language Support
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.