On Fri, Feb 6, 2009 at 10:28 PM, Simon Laws <[email protected]>wrote:
> > > On Fri, Feb 6, 2009 at 4:37 PM, Raymond Feng <[email protected]> wrote: > >> The usage of @Callback in Vamsi's case should be supported too by the >> spec. It's probably a Tuscany bug that has a staled cache based on the >> HelloworldXComponent. >> Vamsi, do you have a test case that we can try? >> >> Thanks, >> Raymond >> >> *From:* Simon Laws <[email protected]> >> *Sent:* Friday, February 06, 2009 6:33 AM >> *To:* [email protected] >> *Subject:* Re: Callback problem with COMPOSITE scoped implementation >> >> >> >> On Fri, Feb 6, 2009 at 2:26 PM, Vamsavardhana Reddy >> <[email protected]>wrote: >> >>> >>> >>> On Fri, Feb 6, 2009 at 5:07 PM, Simon Laws >>> <[email protected]>wrote: >>> >>>> >>>> >>>> On Thu, Feb 5, 2009 at 1:04 AM, Raymond Feng <[email protected]>wrote: >>>> >>>>> Hi, >>>>> >>>>> I realized that I misunderstood the problem after reading your >>>>> case again (where the system hash id for the objects are shown). Sorry >>>>> for >>>>> the confusion. >>>>> >>>>> 1) Tuscany's composite scope management seems to be correct. >>>>> >>>>> 1. HelloworldDelegateComponent is using instance A of >>>>> HelloworldDelegateImpl >>>>> 2. HelloworldDelegateComponent2 is using instance B of >>>>> HelloworldDelegateImpl >>>>> 3. HelloworldXComponent is using instance C of HelloworldImpl. >>>>> 2) Tuscany resolves the target for a callback based on the SCA context >>>>> for the incoming invocation. That's why it works if the scope for >>>>> HelloworldXComponent is >>>>> STATELESS. >>>>> >>>>> 3) When HelloworldXComponent is composite scoped, there is one >>>>> instance. Tuscany runtime probably has some cache that keep the resolved >>>>> callback. And it becomes staled when the 2nd call is coming from a >>>>> different >>>>> component. We'll need to look into the code to fix that. >>>>> >>>>> Vamsi, can you attach your test case to a JIRA? >>>>> >>>>> Thanks, >>>>> Raymond >>>>> >>>>> *From:* Raymond Feng <[email protected]> >>>>> *Sent:* Wednesday, February 04, 2009 1:03 PM >>>>> *To:* [email protected] >>>>> *Subject:* Re: Callback problem with COMPOSITE scoped implementation >>>>> >>>>> Sorry, I took the wrong class name. But the story stays. >>>>> >>>>> In this case is that the "salutation" property is injected. It is >>>>> configured to two different values by the two components. Since Tuscany >>>>> interprets the spec in the 1st way, and there is a single java object >>>>> (sample.HelloworldDelegateImpl) , the field got injected twice and the >>>>> later >>>>> one overrode the first one. That's why you only see the same salutation. >>>>> >>>>> Thanks, >>>>> Raymond >>>>> >>>>> *From:* Vamsavardhana Reddy <[email protected]> >>>>> *Sent:* Wednesday, February 04, 2009 12:47 PM >>>>> *To:* [email protected] >>>>> *Subject:* Re: Callback problem with COMPOSITE scoped implementation >>>>> >>>>> Raymond, >>>>> >>>>> HelloworldDelegateComponent and HelloworldDelegateComponent2 are using >>>>> the implementation class sample.HelloworldDelegateImpl. Both these >>>>> components are invoking a service from HelloworldXComponent which uses >>>>> implementation class sample.HelloworldImpl. Each of these components are >>>>> using a single instance per component of the respective implementation >>>>> classes through out the scope of the composite. Let us say >>>>> 1. HelloworldDelegateComponent is using instance A of >>>>> HelloworldDelegateImpl >>>>> 2. HelloworldDelegateComponent2 is using instance B of >>>>> HelloworldDelegateImpl >>>>> 3. HelloworldXComponent is using instance C of HelloworldImpl. >>>>> >>>>> The problem is that >>>>> a) when A is invoking service from C, C.callback should be injected >>>>> with the callback service provided by A and >>>>> b) when B is invoking service from C, C.callback should be injected >>>>> with the callback service provided by B >>>>> >>>>> Even though it is one instance of HelloworldImpl that is used, the >>>>> callback field should keep changing depending on who is invoking the >>>>> service. Don't know if it is feasible. >>>>> >>>>> On Thu, Feb 5, 2009 at 12:49 AM, Raymond Feng >>>>> <[email protected]>wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> This is interesting. In your case, you have two components >>>>>> HelloworldDelegateComponent and HelloworldDelegateComponent2 that use the >>>>>> same java implementation class: sample.HelloworldImpl which is composite >>>>>> scoped. Now the question is how to interpret the following statement in >>>>>> the >>>>>> SCA java spec: >>>>>> >>>>>> 295 1.2.4.3. Composite scope >>>>>> 296 All service requests are dispatched to the same implementation >>>>>> instance for the lifetime of the containing >>>>>> 297 composite. The lifetime of the containing composite is defined as >>>>>> the time it becomes active in the runtime >>>>>> 298 to the time it is deactivated, either normally or abnormally. >>>>>> >>>>>> There are two ways: >>>>>> >>>>>> 1) There is going to be one instance of sample.HelloworldImpl (A) that >>>>>> are shared by HelloworldDelegateComponent and >>>>>> HelloworldDelegateComponent2. >>>>>> Requests to both components will be dispatched to A. >>>>>> >>>>>> 2) There are going to be two instances of sample.HelloworldImpl (A & >>>>>> B), one for HelloworldDelegateComponent and the other for >>>>>> HelloworldDelegateComponent2. Request to HelloworldDelegateComponent >>>>>> will be >>>>>> dispatched to A while requests to HelloworldDelegateComponent2 will be >>>>>> dispatched B. >>>>>> >>>>>> It seems that Tuscany works in the 1st way. We need clarifications >>>>>> from the spec group. >>>>>> >>>>>> Thanks, >>>>>> Raymond >>>>>> >>>>>> From: Vamsavardhana Reddy >>>>>> Sent: Wednesday, February 04, 2009 8:30 AM >>>>>> To: [email protected] >>>>>> Subject: Callback problem with COMPOSITE scoped implementation >>>>>> >>>>>> >>>>>> >>>>>> I have a composite with three components as given below: >>>>>> >>>>>> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"; >>>>>> targetNamespace="http://sample"; >>>>>> name="HelloworldDelegate"> >>>>>> >>>>>> <component name="HelloworldXComponent"> >>>>>> <implementation.java class="sample.HelloworldImpl"/> >>>>>> </component> >>>>>> >>>>>> <component name="HelloworldDelegateComponent"> >>>>>> <implementation.java class="sample.HelloworldDelegateImpl"/> >>>>>> <service name="HelloworldDelegate"> >>>>>> <binding.ws uri=" >>>>>> http://localhost:8080/tuscany/HelloworldDelegate"/> >>>>>> </service> >>>>>> <reference name="helloworld" target="HelloworldXComponent"/> >>>>>> <property name="salutation">Monsieur</property> >>>>>> </component> >>>>>> >>>>>> <component name="HelloworldDelegateComponent2"> >>>>>> <implementation.java class="sample.HelloworldDelegateImpl"/> >>>>>> <service name="HelloworldDelegate"> >>>>>> <binding.ws uri=" >>>>>> http://localhost:8080/tuscany/HelloworldDelegate2"/> >>>>>> </service> >>>>>> <reference name="helloworld" target="HelloworldXComponent"/> >>>>>> <property name="salutation">Mr.</property> >>>>>> </component> >>>>>> </composite> >>>>>> >>>>>> HelloworldImpl provides a Helloworld service and requires a >>>>>> HelloworldCallback callback service. >>>>>> HelloworldDelegateImpl provides HelloworldDelegate service and >>>>>> HelloworldCallback service. There are two components, namely >>>>>> HelloworldDelegateComponent (with salutation "Monsieur") and >>>>>> HelloworldDelegateComponent2 (with salutation "Mr."). Both these >>>>>> components >>>>>> invoke Helloworld service provided by HelloworldXComponent. >>>>>> Both the implementations are COMPOSITE scoped. >>>>>> >>>>>> When I use the HelloworldDelegate service from >>>>>> HelloworldDelegateComponent the output I see in the console is the >>>>>> following: >>>>>> HelloworldDelegateComponent: >>>>>> HelloworldDelegateImpl(sample.helloworlddelegatei...@28e2f1).sayHello: >>>>>> vamsi >>>>>> HelloworldXComponent: >>>>>> HelloworldImpl(sample.helloworldi...@10076aa).sayHello: >>>>>> vamsi >>>>>> HelloworldDelegateComponent: >>>>>> HelloworldDelegateImpl(sample.helloworlddelegatei...@28e2f1).whoIs: >>>>>> vamsi >>>>>> >>>>>> and the message got back is "Hello Monsieur vamsi". >>>>>> ------------------------------ >>>>>> When I use the HelloworldDelegate service from >>>>>> HelloworldDelegateComponent the output I see in the console is the >>>>>> following: >>>>>> HelloworldDelegateComponent2: >>>>>> HelloworldDelegateImpl(sample.helloworlddelegatei...@146e74b).sayHello: >>>>>> vamsi >>>>>> HelloworldXComponent: >>>>>> HelloworldImpl(sample.helloworldi...@10076aa).sayHello: >>>>>> vamsi >>>>>> HelloworldDelegateComponent: >>>>>> HelloworldDelegateImpl(sample.helloworlddelegatei...@28e2f1).whoIs: >>>>>> vamsi >>>>>> >>>>>> and the message got back is "Hello Monsieur vamsi". I was expecting >>>>>> "Hello Mr. vamsi". >>>>>> >>>>>> Notice that in the second case, the callback service is called from >>>>>> HelloworldDelegateComponent instead of HelloworldDelegateComponent2. Is >>>>>> this >>>>>> the expected behaviour? >>>>>> ----------------- >>>>>> >>>>>> If I make HelloworldImpl as STATELESS scoped (which is the default), >>>>>> then I am seeing that the callback service is invoked on the same >>>>>> component >>>>>> that is invoking the Helloworld service. The following is the output: >>>>>> >>>>>> HelloworldDelegateComponent: >>>>>> HelloworldDelegateImpl(sample.helloworlddelegatei...@1c704a7).sayHello: >>>>>> vamsi >>>>>> HelloworldXComponent: >>>>>> HelloworldImpl(sample.helloworldi...@1af0f92).sayHello: >>>>>> vamsi >>>>>> HelloworldDelegateComponent: >>>>>> HelloworldDelegateImpl(sample.helloworlddelegatei...@1c704a7).whoIs: >>>>>> vamsi >>>>>> Hello Monsieur vamsi >>>>>> >>>>>> HelloworldDelegateComponent2: >>>>>> HelloworldDelegateImpl(sample.helloworlddelegatei...@61dec0).sayHello: >>>>>> vamsi >>>>>> HelloworldXComponent: >>>>>> HelloworldImpl(sample.helloworldi...@4f3d72).sayHello: >>>>>> vamsi >>>>>> HelloworldDelegateComponent2: >>>>>> HelloworldDelegateImpl(sample.helloworlddelegatei...@61dec0).whoIs: >>>>>> vamsi >>>>>> Hello Mr. vamsi >>>>>> >>>>>> What am I missing? >>>>>> >>>>>> ++Vamsi >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Vamsi >>>>> >>>> >>>> Isn't it just that the the @Callback is injected once when the COMPOSITE >>>> scoped component is created that is causing the caching of the callback and >>>> hence the problem in this scenario. >>>> >>>> What happens if you use RequestContext.getCallback()? >>> >>> With RequestContext.getCallback(), it is working as expected. >>> >>> >>>> >>>> >>>> Simon >>>> >>> >>> >>> >>> -- >>> Vamsi >>> >> >> Hi Vamsi >> >> So what you mean by "working as expected." is that the callback goes to >> the client that originates each call as opposed to the first client that is >> injected when you use the inject callback? >> >> If yes this underlines the fact that Tuscany has the right information and >> is able to create the right proxy. It's just not able to inject it into a >> component whose scope extends over more than one call. >> >> Simon >> > > Hi Raymond > > Let me check I understand what you're saying here. If I have a component > defined as follows > > @Scope("COMPOSITE") > class MyComponentImpl implements MyComponent { > > protected MyCallback myCallback; > > @Callback > public setMyCallback (MyCallback myCallback) { > this.myCallback = myCallback; > } > > void doSomething(){ > myCallback.doTheCallback(); > } > } > > with multiple concurrent threads passing through doSomething() your > proposition is that the injected myCallback is fixed under the covers to > point to the target indicated on each incoming message? I suppose so. > > > Simon > -- Vamsi
