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.


-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to