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]
>
>
