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.
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: < [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]
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
