Also Mark is right that an InterceptorFactory can use any technology to implement the interceptor. So maybe for the article DynaProxies could be fine. (in the test package there is a ServiceInterceptorFactory using a DynaProxy - org.apache.commons.hivemind.lib.methodinter.test.LogProxyInterceptorFactory - it's very easy)
PS.:
Why use another Bytecode generation toolkit when Apache has its own (BCEL)?First I don't realy know BCEL (yes I should change that). Second HiveMind already depends on Javassist and it's realy easy to use especially with the HiveMind support classes. I will certainly take a look at repast-jellytag.
On Tue, 25 Nov 2003 09:12:44 -0500, Mark R. Diggory <[EMAIL PROTECTED]> wrote:
Why use another Bytecode generation toolkit when Apache has its own (BCEL)?
I wrote some JellyTags awhile back that used BCEL so that you can basically create Bean classes on the fly using BSF. There was some talk of making them "Dynabeans" but I got into other projects and that has stalled.
http://repast-jellytag.sourceforge.net/bcel/tags.html
ServiceInterceptorFactory is a novel idea which I like, an interceptor could be of various implementations (java, BCEL Javassist) and doesn't neccessarily need to be something specific to HiveMind, Jelly, what have you....
-Mark
James Carman wrote:
I like the idea of this hybrid approach! I am NOT a fan of using javassist
to write interceptors. I am writing an article for TheServerSide.com about
HiveMind currently. Is this code available somewhere? I don't plan on
demonstrating how to write a purely javassist-based interceptor, as I do not
feel it is very intuitive. However, this simpler approach does seem to be a
nice compromise and I would like to present it.
-----Original Message-----
From: Christian Essl [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 25, 2003 7:38 AM
To: [EMAIL PROTECTED]
Subject: [HiveMind] New interceptor support
Javassist is fast and impressingly easy for byte-code generation, however it is by no way that comfortable (to code, test and debugg) as plain java. Therefore I've implemented an abstract ServiceInterceptorFactory which allows the user to attach MethodInterceptors to the methods of an interface. (A common pattern used by aopalliance, spring, cglib etc). Ie a simple tracing interceptor looks like this:
public class TracingMethodInterceptor implements MethodInterceptor
public Object invoke(Invocation invocation, Object target, Object[] args) throws Throwable
{
System.out.println("method: "+invocation.getMethod()+" is called with args: "+args);
Object ret = invocation.proceed(target, args); //this invokes the next method in the interceptor chain
System.out.println("method: "+invocation.getMethod()+" returned: "+args) ;
return ret;
}
}
Both the interceptor and the Invocation are created using Javassist, therefore it is in terms of speed (according to my rudimentary testings) between a plain Javaassist interceptor and a dyna-proxy interceptor.
Comparing the existing Hivemind Logging with the same code using the MethodInterceptor and with a DynaProxy for 5.000.000 repetitions the times (ms) are as follows: (The numbers are not stable but the direction is quite clear)
method: Object getObject() executing MethodLog took: 1000 executing HivemindLog took: 359 executing DynaProxyLog took: 1360
method: void setObject(Object); executing MethodLog took: 968 executing HivemindLog took: 516 executing DynaProxyLog took: 1766
method (9 prim params): int add(int,int,byte,short,char,double,long,float);
executing MethodLog took: 3063 (more primitives and arguments means bigger args[] and boxing/unboxing)
executing HivemindLog took: 594
executing DynaProxyLog took: 4031
As I see interceptors for general use should be created using javaassist, however other interceptors (which just add some custom AOP for some components) could well be implemented using MethodInterceptors. Here the higher convinience pays off.
-- Christian Essl http://jucas.sourceforge.net
methodinter.zip
Description: Zip compressed data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
