Re: svn commit: r438785: move to ServiceContract/Operation

[Jim Marino]

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]