geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nokleberg <ch...@sixlegs.com>
Subject Re: bytecode interceptors
Date Tue, 02 Dec 2003 19:29:26 GMT
James Strachan wrote:
> Saw this in the blogosphere today...
> 
> http://kasparov.skife.org/blog/2003/12/01#thank-you-chris
> 
> thought it looked interesting.  I wonder if we could look at integrating
> this kind of feature ('baking' an interceptor stack into bytecode)

The implementation isn't going quite that far. It's probably similar to what
you currently do. A proxy is created that stubs out to a list of
interceptors. The baking process is probably just freezing that list (maybe
into an array or something).

What you propose is possible, of course. The savings would be from:
 - elimination of need for invocation object
 - no need for invokevirtual method to start invocation process
 - replacement of invokeinterface calls to actual interceptors with
   hard-coded invokevirtual calls
 - removal of synchronization (don't have to prevent chains from being   
   modified during invocation)

Not sure how much of this applies to Geronimo. It's not terribly hard to do,
but to add something like this to CGLIB I'd obviously want to find a way
not to have to tie it to Geronimo's interceptor classes. Let me know...

If you have complete control over the container startup and classloading (as
you probably do) then AOP is a viable solution too, but in general run-time
code generation is much more portable. FYI CGLIB2 can also use the
Aspectwerkz "online mode" architecture to hook into the ClassLoaders of the
various JVMs, but for this use-case it is unnecessary.

Chris



Mime
View raw message