Hi Jim, Please see my further queries below and let me know if my thinking is right.
On 8/31/06, Jim Marino <[EMAIL PROTECTED]> wrote:
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.
Venkat : Ok.. will use ASM. 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).
I follow this. So here is what I understand as, to be done: - for the logic in 'createProxy' method of the JDKWireService generate a class using ASM that implements the wire's interface - let us call this 'generatedProxy' - depending on the number of methods, create as many fields in this generatedProxy to hold instances of the InvocationChain - implement the body of each method in this 'generatedProxy' to execute all of the logic in JDKOutboundInvocationHandler (or other inbound hanlder as the case may be) using the appropriate field that holds its corresponding 'InvocationChain' instance. Having generated the bytecode for this 'generatedProxy' create an instance of it and return that as return value for the 'createProxy' method. Is this right? 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
As an when I get info on this I shall make the relevant changes. Is that ok ? Thanks - Venkat 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]
