I'd prefer ASM (CGLIB is built using it) since it is smaller, easier
to use (CGLIB documentation is awful) and will probably give us more
flexibility.
What we need to do is provide an implementation of WireService that
uses an approach which dispatches method invocations directly to the
correct invocation chain. The JDK wire service currently creates
invocation handlers that resolve the chain to invoke based on the
method passed in from the proxy. We should be able to generate proxy
code that does a "static" invoke to the correct chain without the
overhead of a map lookup (see the JDK-based implementations of
invocation handler). In addition, we should be able to create
optimized variants of WireInvocationHandler. We particularly need to
optimize JDKCallbackInvocationHandler and the
JDKOutboundInvocationHandler constructor.
As a note, I still need to switch over WireInvocationHandler.invoke
(Method method, Object[] args) to take an Operation instead of a method.
Geronimo I believe uses something similar so perhaps Jeremy could
describe it further? I've also seen this done in Aspectwerkz with
extremely fast performance.
Jim
On Aug 31, 2006, at 12:04 AM, Venkata Krishnan wrote:
Hi Jim,
I worked a bit with cglib to generate manipulated intefaces as
apart of
the RMI-Binding and JavaScript e4x stuff. If this is good for a
start, then
please let me know what is to be done in JDKWireService. Thanks
- Venkat
On 8/31/06, Jim Marino <[EMAIL PROTECTED]> wrote:
I have committed the changes to use ServiceContract/Operation in
place of Java Interface/Method. This entailed modifications in SPI,
particularly the signatures for classes in the wire package (e.g.
RuntimeWire, InvocationChain), WireService, and Component
(createTargetInvoker).
ServiceContracts are created by an introspection registry for a given
IDL. These registries may use the same pattern as registries for
loaders and builders. For example, Java IDL has a
JavaInterfaceProcessorRegistryImpl that delegates to
JavaInterfaceProcessor implementations to populate a ServiceContract
reflected from a Java interface. JavaInterfaceProcessor
implementations may be system services which register with a
JavaInterfaceProcessorRegistry, thereby adding support for metadata
extensions (such as information specific to a databinding type).
ServiceContract metadata is used to decorate wires. RuntimeWire has
a new method getServiceContract() which will return the service
contract associated with an inbound or outbound wire. Similarly,
Invocation chains are decorated with an Operation. This metadata will
be used by a new system service responsible for "optimizing/
mediating" wires as they are connected by the wiring infrastructure.
This system service will be another registry with a set of builders.
It will be different than the policy builder registry since policy
builders only operate on one side of a wire (source or target).
Raymond's databinding framework will use these facilities to
introspect the outbound and inbounds parts of a wire and add
appropriate interceptors.
Currently, Operation and ServiceContract do not have facilities for
runtime extensibility metadata; I will be adding these along with the
new type of "optimizing/mediating" registry (probably) tomorrow.
One outstanding work item is to provide a performant replacement for
JDK proxies (JDKWireService). I suspect we will see significant
performance penalties for local invocations, particularly callbacks,
as several map lookups are done. If anyone is interested in creating
an implementation of WireService based on a bytecode generation
library such as ASM, please let me know and I will try and provide
pointers.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
