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.
-Brian
On Dec 2, 2003, at 2:29 PM, Chris Nokleberg wrote:
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
