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