> and do stuff with it. So really it means that while
> we would maintain the configuration as is, meaning
> that we would support the basic read-ahead setting as
> it is today, it allows for overridding of that
> property BY THE CLIENT.
Yes that is cool. So that is a reason to keep state at the proxy level for configuration.
> today, it is the commit-option field in the cache
> interceptor but the point is HOW DO WE GET AT THAT
> INTERCEPTOR in a standardized way.
How do we get at an interceptor in a standard way? Redeploy it! Modify the .aspect xml file and redeploy it. For JMX we would need an XML editor MBean that wrapped the .aspect xml file. You understanding what i'm saying? The JMX XML Editor MBean would be attached to the .aspect xml file and would have a save button.
I'm sick of MBean config being non-persistent. Its our last hurdle before becoming a real light-weight component model.
> then that map has an adapter that retrieves the
> setters from the interceptors. So that cache
> interceptor has setCommitOption(). The adapter knows
> that the interceptors wants the "commitOption" call
> so when the value changes the adapter that holds the
> pointer to the interceptor (that adapater is built at
> deployment time) will call the interceptor with
I like this adapter idea too. We just need to make sure that everything is layered here. We want the Aspect framework to be lightweight and usable as a library, a JAR file.
> the mapping of names to method needs to be something
> dumb like "remove - lowercase everyone and set the
> This way we solve the problem of coding style while
> retaining the centralized approach to configuration.
> This is uber powerful. One of the applications of
> this is if we have a cluster running we can call the
> configuration on the whole cluster easily.
> it is good infrastructure.
> Do we see eye to eye on this one?
Yes centralized configuration is good. But you should be able to override.
At Iona we had the idea of configuration scopes. Scopes could inherit off of one another. So if your current scope didn't have a config value defined it looked to the parent for the value.
We could have configuration scopes for our Aspects.
Invocation-Config-Scope extends Proxy's-config-scope extends Global-config-Scope.
So whenever an aspect needs config info it asks the InvocationScope->Proxy's Scope->GlobalScope.
So a user can modify configuration on different levels. For the duration of the method call, for a specific reference to a object, or globally for all.
You get what I'm saying?
That's an interesting question. According to
the developers of ObjectWeb ASM, ASM is
10 times faster than BCEL and around 10%
faster than Javassist. I forgot the exact
numbers, but BCEL seems very slow because
of their old-fashioned internal architecture.
ASM is a very small light-weight library for
modifying bytecode; it does not provide
source-level abstraction that Javassist does.
However, the argument above does not mention
the compilation by Javassist since the other
libraries do not provide a compiler. In fact, the
benchmark by ASM people is a very much toy.
I don't have any numbers with respect to the
compilation speed by Javassist, but I think the
overhead is not as big as you expect. But yes,
I need some experiments for further discussion
on this topic.