Hi Jim... did you get a chance to look at this. :) - Venkat
On 9/4/06, Jim Marino <[EMAIL PROTECTED]> wrote:
Great. I'll take a look. Jim On Sep 4, 2006, at 2:14 AM, Venkata Krishnan wrote: > Hi Jim, > > I have posted a patch for this in > http://issues.apache.org/jira/browse/TUSCANY-690. Please take a > look and > let me know if I that is what you had in mind ;-). Also let me > know what > more might need to be done. > > I have made quite a few changes to classes in the > org.apache.tuscany.core.wire and > org.apache.tuscany.core.wire.jdkpackages. I have also added two > classes... > > - AbstractInvocationHandler in the org.apache.tuscany.core.wire > package to > abstract out some common function related to chain holder and > caching target > invokers. > - ProxyFactory in org.apache.tuscany.core.wire.jdk to create the proxy > instances. This could probably be a good place to cache the > bytecodes as > well. > > Please let me know if this is what is in your mind and also let me > know how > to proceed further in this. > > Thanks > > - Venkat > > On 9/4/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: >> >> 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: tuscany-dev- >> [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] >> > >> > >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
