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
