geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <>
Subject Re: bytecode interceptors
Date Fri, 12 Dec 2003 01:52:45 GMT
Chris just pointed me at this discussion -- if we can make the 
intercept library useful for ya'll, let me know. I am putting together 
some benchmarks on various oddities now.


On Dec 2, 2003, at 2:29 PM, Chris Nokleberg wrote:

> James Strachan wrote:
>> Saw this in the blogosphere today...
>> 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

View raw message