|
#1
|
|||
|
|||
|
Hi Alls,
I have 3 methods in my class Code:
public void startRuleSet() {
System.out.println("Start Rule Set");
makeRule1();
makeRule2();
}
public void makeRule1() {
System.out.println("Rule 1");
}
public void makeRule2() {
System.out.println("Rule 2");
}
Code:
<bean id="myBefore" class="com.my.test.aop.MyBefore"/>
<bean id="ruleSetAOPTest" class="com.my.test.aop.RuleSetAOPImpl"/>
<bean id="ruleAdvisor"
class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
<property name="advice">
<ref local="myBefore"/>
</property>
<property name="pattern">
<value>.*Rule.*</value>
</property>
</bean>
<bean id="ruleSetBean" class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="target">
<ref local="ruleSetAOPTest"/>
</property>
<property name="proxyTargetClass">
<value>true</value>
</property>
<property name="interceptorNames">
<list>
<value>ruleAdvisor</value>
</list>
</property>
</bean>
Code:
final RuleSetAOPImpl ruleSet = (RuleSetAOPImpl) context.getContext().getBean("ruleSetBean");
ruleSet.startRuleSet();
Is it possible ? Thank's |
|
#2
|
|||
|
|||
|
Please take a look at AOP, Proxies, and method calling in same instance and Pre-Interceptor in TransactionProxyFactory.
HTH |
|
#3
|
|||
|
|||
|
But in this case object has to know about AOP and that it is interceptored now.
I don't like such solution because i need clean pojo not agly hybrid. Quote:
|
|
#4
|
|||
|
|||
|
As I said in a previous post, this approach is intrusive. You may, however use AspectJ for less intrusive approach.
|
|
#5
|
|||
|
|||
|
I cann't do it because my class instanses will load from db.
And i think it's impossible to use AspectJ in such case only runtime byte code manipulation. Quote:
|
|
#6
|
|||
|
|||
|
Quote:
What about this : I think this problem could be "partially" solved with the use of CLIB instead of Dynamic Proxies : since the target class will be subclassed, calls to this() will first cause the overriden method to execute, thus allowing the AOP mechanism to work. Of course there will still be some problems here with CGLib, since all the methods marked as "final" cannot be subclassed Do I have the point ? Or did I miss something ? |
|
#7
|
|||
|
|||
|
You're right. I made this thing using cglib
Quote:
|
|
#8
|
|||
|
|||
|
Quote:
Using CGLIB proxies will not solve this problem as, just like JDK proxies, they delegate to the target. See: http://forum.springframework.org/showthread.php?t=9926 Ollie Last edited by robyn; May 16th, 2006 at 03:51 AM. |
|
#9
|
|||
|
|||
|
You're wrong
when i have 3 public methods: Code:
public a() {
b();
c();
}
public b() {...}
public c() {...}
Quote:
Last edited by robyn; May 16th, 2006 at 03:50 AM. |
|
#10
|
|||
|
|||
|
I would say the difference between Java proxies and CGLIB proxies is the following:
A Java proxy effectively establishes a delegate. You call a method on the proxy which eventually delegates to the target. Once inside the target's method the invocation of another method will take place in the context of the target, not of the proxy. I assume a CGLIB proxy establishes a subclass of the target class. So you never leave the context. Operating on "this" effectively operates on the subclass (proxy) instance. So subsequent invocations take place on the proxied methods (if not private). It's a difference between delegation and inheritance, therefore the former does not work while the latter does. Regards, Andreas P.S.: I'm no expert for CGLIB. It's just an explanation of how I think it works |
![]() |
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Order of Bean definitions matters? | cfuser | Core Container | 2 | Oct 21st, 2005 10:29 AM |
| Spring container fails with no exception | naor | Core Container | 9 | Oct 1st, 2005 03:39 PM |
| EHCaching Hibernate | dencamel | Data Access | 3 | Sep 6th, 2005 09:03 PM |
| Stack Overflow | rayho222 | Core Container | 6 | May 17th, 2005 03:42 AM |
| Method call why not be intercepted by MethodSecurityIntercep | aaron8tang | Spring Security | 8 | Dec 7th, 2004 06:13 PM |