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. (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. If I am still not clear please let me know and probably testcase is the only way out. 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: [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]
