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