HI Jim,
Yes, the pass-by-value interceptor will come first exactly for the
reasons
you have mentioned. I will get a testcase across soon.
Thanks
- Venkat
On 12/6/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>
>
> On Dec 5, 2006, at 10:51 PM, Venkata Krishnan wrote:
>
> > Hi,
> >
> > I think I managed to figure this out now. After your
explanation I
> > could
> > follow the Connector a little better. Its just that the outbound
> > (of the
> > source component) and inbound chains (of the target component)
are
> > fused
> > thro the bridge interceptor.
> >
> > Given this if I added an interceptor to the begining of the
> > target's inbound
> > chain then I must have to reset the source's tail interceptor to
> > point this
> > this added interceptor as its next. (Infact I found this code
> > marked as
> > "HACK" further down the DataBindingWirePostProcessor). This
is what I
>
> > intend to do.
> We probably should do something to make this less error-prone in
the
> fabric...I'll take a look.
> >
> > On the other hand if I were to add an intercetpr to the end of
the
> > target's
> > inbound chain then I end with an exception because the tail is
> > already an
> > InvokerInterceptor and nothing can be added beyond that.
> The pass-by-reference interceptor needs to come first since
> interceptors could modify a the payload of a message. This can
> violate pass-by-value semantics if a copy is not made beforehand.
>
> > So in this case I
> > have to probably iterate thro all interceptors and then insert
just
> > before
> > the InvokerInterceptor.
> >
> > So.. I am moving forward for now. Thanks for the help.
> >
> Can you post a testcase so I can see how best to make this less
error-
> prone as mentioned above? Thanks.
>
> Jim
>
> > - Venkat
> >
> >
> >
> >
> >
> > On 12/5/06, Jim Marino <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >> 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: <tuscany-dev@ws.apache.org >
> >> >> >> 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: <tuscany-dev@ws.apache.org>
> >> >> >> >> 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: <tuscany-dev@ws.apache.org >
> >> >> >> >> >> 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: 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]
>
>
