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: tuscany-dev-
[EMAIL PROTECTED]
>> > >> >> For additional commands, e-mail: tuscany-dev-
>> [EMAIL PROTECTED]
>> > >> >>
>> > >> >>
>> > >>
>> > >>
>> > >>
>>
---------------------------------------------------------------------
>> > >> 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]
