On Dec 5, 2006, at 1:34 AM, Venkata Krishnan wrote:
> Hi Jim,
>
> Thanks for helping :). Well, let me ask away very simply....
>
> What I am doing here is just about trying to insert an
interceptor for
> enforcing pass-by-value semantics in the case of compoments
> implementing a
> Remotable interface - i.e. an interceptor to take care of making
> copies of
> arguments and return values.
>
> Since I understand that the best place to perform such a copying
> would be
> just before the serving (or provider) component actually gets to
> service the
> request, I had thought of inserting this interceptor into the
> InboundInvocation chain of the server component.
>
> For example if component A that has a reference to Component B
whose
> interface is remotable. Then I am trying to insert this
> interceptor into
> Component B's Inbound wire's invocation chain. This I do in the
> DataBindingWirePostProcessor.process(OutboundWire source,
InboundWire
> target) wherein 'target' is the wire where I am doing the
insertion.
Pass-by-val should probably be enforced in another wire processor
since it is a separate concern (this isn't related to the problem
though)
> (Component A being the source and Component B being the target).
> When I
> tested this, the interceptor seemed to not get invoked.
>
> However, when I added this interceptor to the source component's
> outbound
> chain i.e. in DataBindingWirePostProcessor.process(OutboundWire
> source,
> InboundWire target) to the invocation chain of the 'source',
then the
> interceptor got invoked.
>
> So right now, I am wondering how to get the interceptor invoked
> from the
> Inbound invocation chain of Component B.
>
It sounds like something is not being setup properly
> If I am still not clear please let me know and probably testcase is
> the only
> way out.
>
This would be the easiest way (you can probably copy the testcase I
pointed to, so it's not that much work). Such a testcase will allow
you to set a breakpoint and see if the target chains have been
sequenced properly. It sounds like upon insertion your interceptor
is not being pointed to by the previous one in the chain. It is
possible that there is a problem in the wiring infrastructure that is
causing this to happen.
Jim
> Thanks
>
> - Venkat
>
>
>
>
> On 12/5/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>>
>> Comments inline...
>>
>> On Dec 5, 2006, at 12:29 AM, Venkata Krishnan wrote:
>>
>> > Hi Raymond,
>> >
>> > Yes, I am debugging to figure out quite a few things.
>> >
>> > I just figured that in the ConnectorImpl.connect(OutboundWire
>> > sourceWire,
>> > InboundWire targetWire, boolean optimizable) we set the
>> > 'targetInvoker' of
>> > the 'targetComponent' to the outbound chain of the source.
Hence I
>> > guess
>> > the interceptors of set on the inbound chain of the
targetComponent
>> > is not
>> > getting invoked.
>> >
>> > I am looking to see if there is a way where at the end of the
>> > OutboundWire's
>> > invocation chain the target invoker triggers off the target
>> > component's
>> > inbound invocation chains.
>> >
>> The TargetInvoker's job is to dispatch a request to the target
>> instance *after* the request has been processed by the invocation
>> chain pair. The invoker is cached on the source side to avoid
having
>> to perform target resolution on every invoke in certain situations
>> (e.g. when the target scope is "greater" than the source,e.g.
>> request--->composite). The invocation handler places the
>> TargetInvoker in the message sent down both chains and it is the
>> responsibility of the last interceptor on the target side to
pull the
>> invoker from the message and call its invoke method.
>>
>> The source and target chains are fused by the Connector with a
>> BridgingInterceptor, which may be synchronous or non-blocking.
>>
>> I'm finding it a little difficult to follow what you are doing
so do
>> you have a small testcase you can attach to a JIRA similar to
this:
>>
>> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/
kernel/
>> core/src/test/java/org/apache/tuscany/core/integration/
conversation/
>> ConversationStartStopEndTestCase.java
>>
>> I can take a look and see what the problem is.
>>
>> Jim
>>
>> > I am still going at this... let me see if I see the light.
>> >
>> > Meanwhile if I am not on the right track (anybody) please advise
>> me on
>> > course corrections :)
>> >
>> > Thanks.
>> >
>> > - Venkat
>> >
>> >
>> >
>> > On 12/5/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Can you debug to see how the interceptors are chained? It
could be
>> >> a bit
>> >> tricky to make sure the new interceptor is added to the correct
>> >> position.
>> >>
>> >> Thanks,
>> >> Raymond
>> >>
>> >> ----- Original Message -----
>> >> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
>> >> To: <[email protected]>
>> >> Sent: Monday, December 04, 2006 4:16 PM
>> >> Subject: Re: Pass-by-value support for remotable interfaces
>> >>
>> >>
>> >> > Hi Raymond,
>> >> >
>> >> > Thanks. I have started with this and here are a couple of
>> >> questions
>> >> that
>> >> > I
>> >> > need help with.
>> >> >
>> >> > I believe the PassByValue Interceptor is good to be on the
>> Inbound
>> >> > Invocation chain of the server component. Accordingly I
looked
>> >> up the
>> >> > DataBindingWirePostProcessor's method -
>> >> > "public void process(OutboundWire source, InboundWire
target)"
>> >> to do
>> >> this.
>> >> >
>> >> > Over here I added the PassbyValue interceptor to the
'target'.
>> >> But this
>> >> > did
>> >> > not invoke the interceptor. If I added it to the source then
>> the
>> >> > interceptor gets invoked. So, am I missing something here?
>> >> >
>> >> > I understand that the interceptor that you have attached is
>> for the
>> >> > default
>> >> > Java binding case. I will work on the databinding dependent
>> >> case once I
>> >> > get
>> >> > this default stuff working.
>> >> >
>> >> > Thanks
>> >> >
>> >> > - Venkat
>> >> >
>> >> >
>> >> >
>> >> > On 12/4/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >> Hi, Venkat.
>> >> >>
>> >> >> Thank you for volunteering. I opened a JIRA
>> >> >> http://issues.apache.org/jira/browse/TUSCANY-969 and
>> attached some
>> >> >> prototype
>> >> >> code there. Hopefully it can get you started.
>> >> >>
>> >> >> Thanks,
>> >> >> Raymond
>> >> >>
>> >> >> ----- Original Message -----
>> >> >> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
>> >> >> To: <[email protected]>
>> >> >> Sent: Sunday, December 03, 2006 10:08 PM
>> >> >> Subject: Re: Pass-by-value support for remotable interfaces
>> >> >>
>> >> >>
>> >> >> > Hi Raymond,
>> >> >> >
>> >> >> > I'm interested in helping with this. It will give me a
>> >> chance to
>> >> work
>> >> >> > with
>> >> >> > the service invocation paths of the core. Let me know if
>> >> there is
>> >> >> > something
>> >> >> > that I help with.
>> >> >> >
>> >> >> > Thanks.
>> >> >> >
>> >> >> > - Venkat
>> >> >> >
>> >> >> > On 11/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >> >> >>
>> >> >> >> ----- Original Message -----
>> >> >> >> From: "Mike Edwards" <[EMAIL PROTECTED]>
>> >> >> >> To: <[email protected] >
>> >> >> >> Sent: Wednesday, November 29, 2006 7:07 AM
>> >> >> >> Subject: Re: Pass-by-value support for remotable
interfaces
>> >> >> >>
>> >> >> >>
>> >> >> >> > Raymond,
>> >> >> >> >
>> >> >> >> > First point I need to make is that just because two
>> >> components are
>> >> >> >> > in
>> >> >> >> the
>> >> >> >> > same composite does not mean that they are
automatically
>> >> running
>> >> in
>> >> >> the
>> >> >> >> > same VM or even the same operating system process.
>> >> Composites can
>> >> >> span
>> >> >> >> > components running on different nodes (node =
machine and/
>> >> or o/s
>> >> >> >> process).
>> >> >> >> >
>> >> >> >>
>> >> >> >> Good catch.
>> >> >> >>
>> >> >> >> > Consider a composite which had component A
implemented in
>> >> Java and
>> >> >> >> > component B implemented in C++. Not likely that they
>> >> would run in
>> >> >> the
>> >> >> >> > same runtime process (certainly not with the current
>> Tuscany
>> >> >> runtime).
>> >> >> >> > This is perfectly OK as long as any interface between
>> them is
>> >> >> >> "remotable".
>> >> >> >> >
>> >> >> >> > Second, more general point to make, is that there
may be
>> >> implied
>> >> >> >> semantics
>> >> >> >> > for the interface that depend on the binding used to
>> >> connect the
>> >> >> >> reference
>> >> >> >> > to the service. Consider the case where the interface
>> >> involves an
>> >> >> >> > operation with a message having two references to
the same
>> >> object.
>> >> >> >> > When
>> >> >> >> > this is sent from consumer to provider (say), does the
>> >> provider
>> >> >> receive
>> >> >> >> 2
>> >> >> >> > separate copies of the object or just one - assuming
the
>> >> consumer
>> >> >> >> started
>> >> >> >> > with only 1.
>> >> >> >> >
>> >> >> >> > The answer is "it depends on the binding" - RMI-IIOP
says
>> >> there is
>> >> >> only
>> >> >> >> 1
>> >> >> >> > copy. Web Services says there are 2 copies...
>> >> >> >> >
>> >> >> >> > I don't think that SCA can hide these subtle
differences,
>> >> much
>> >> >> >> > though
>> >> >> >> > we
>> >> >> >> > may like to do so. However, what we must guarantee is
>> >> that the
>> >> >> >> behaviour
>> >> >> >> > matches the binding type - if the internal wire uses
>> >> binding.ws,
>> >> for
>> >> >> >> > example, then we provide Web services semantics. This
>> >> must be
>> >> true
>> >> >> for
>> >> >> >> > any optimisations we may like to use in the case where
>> >> both ends
>> >> of
>> >> >> the
>> >> >> >> > wire are in 1 process - since for a remotable interface
>> this
>> >> >> proximity
>> >> >> >> is
>> >> >> >> > "accidental" and could be changed by a subtle change in
>> >> deployment.
>> >> >> >> >
>> >> >> >> > That leaves open what to do in the case of
binding.ws. We
>> >> may
>> >> need
>> >> >> >> > a
>> >> >> >> way
>> >> >> >> > for the composition to indicate the type of semantics
>> >> required -
>> >> or
>> >> >> we
>> >> >> >> > could default to one form (eg Web services...)
>> >> >> >> >
>> >> >> >>
>> >> >> >> Should this be clarified by the SCA spec on pass-by-
value?
>> >> >> >>
>> >> >> >> >
>> >> >> >> > Yours, Mike.
>> >> >> >> >
>> >> >> >> > Raymond Feng wrote:
>> >> >> >> >> Hi,
>> >> >> >> >>
>> >> >> >> >> I'm talking about the following:
>> >> >> >> >>
>> >> >> >> >> componentA.reference --> componentB.service1
>> >> >> >> >> non-SCA client --> componentB.service1
>> >> >> >> >>
>> >> >> >> >> In the cases above, componentA and componentB are
in the
>> >> same
>> >> >> >> >> composite
>> >> >> >>
>> >> >> >> >> (in the same VM). Both the service and reference are
>> >> declared
>> >> with
>> >> >> >> >> a
>> >> >> >> >> remotable interface. We need to have an interceptor to
>> >> deal with
>> >> >> >> >> the
>> >> >> >> >> pass-by-value.
>> >> >> >> >>
>> >> >> >> >> For the following wirings:
>> >> >> >> >>
>> >> >> >> >> .. --> composite.reference
>> >> >> >> >> composite.service --> ...
>> >> >> >> >>
>> >> >> >> >> I assume the binding implementation for the composite
>> >> >> >> >> reference/service
>> >> >> >> >> will handle the pass-by-value naturally over the
>> transport.
>> >> >> >> >>
>> >> >> >> >> Thanks,
>> >> >> >> >> Raymond
>> >> >> >> >>
>> >> >> >> > <snip>
>> >> >> >> >
>> >> >> >> >
>> >>
>>
---------------------------------------------------------------------
>> >> >> >> > To unsubscribe, e-mail: tuscany-dev-
>> [EMAIL PROTECTED]
>> >> >> >> > For additional commands, e-mail: tuscany-dev-
>> >> [EMAIL PROTECTED]
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >>
>>
---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: tuscany-dev-
>> [EMAIL PROTECTED]
>> >> >> >> For additional commands, e-mail: tuscany-dev-
>> [EMAIL PROTECTED]
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >>
>>
---------------------------------------------------------------------
>> >> >> 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: [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]
