On Dec 6, 2006, at 1:52 AM, Venkata Krishnan wrote:
> Hi,
>
> Is there any way I can control the order in which the
> WirePostProcessors are
> loaded. For example I would always want the PassByValue processor
> to be
> called last so that I ensure that the PassByValue interceptor is at
> the head
> of the invocation chain.
>
The best way to handle this is by implementing a phase mechanism. I
can look into adding this. BTW, why is this a WirePostProcessor vs. a
TargetPolicyBuilder (which has phases)?
Jim
> Thanks.
>
> - Venkat
>
> On 12/6/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>>
>> 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]
>> >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
