Hi Jim, Just to keep you updated.. I have stared on this and have got some code up for this. I am currently working on getting it work. ;-) trying to get around with the ASM utilities and APIs. Should be done with it soon.
Thanks - Venkat On 9/2/06, Jim Marino <[EMAIL PROTECTED]> wrote:
Sorry for the delay... On Aug 31, 2006, at 10:26 AM, Venkata Krishnan wrote: > 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' I separated out common logic into AbstractInboundInvocationHandler and AbstractOutboundInvocationHandler so you should be able subclass those. We will eventually have to do a callback invocation handler as well but this is in flux so I would concentrate on the two for now. > - 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. > If you subclass the new abstract classes, you will just have to implement the indexing mentioned above. > 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? > Yep. We may also want to profile performance of the generation and see if we want to do caching of generated bytecode. I'm going to ask the Aspectwerkz guys about this since they used ASM in a similar way and did extensive performance analysis. Jim > > 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
