[jira] Commented: (TUSCANY-1909) Conversational Component referring to another Conversational Component always uses the same instance

["Mark Combellack (JIRA)" <tu...@ws.apache.org>]

    [ https://issues.apache.org/jira/browse/TUSCANY-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542207 ] 

Mark Combellack commented on TUSCANY-1909:
------------------------------------------

After some investigation, it appears that the problem is caused by the conversationPreinvoke() method in the JDKInvocationHandler. As part of the pre-invoke handling for conversational components, it checks if a conversation has been started. If it has not, it starts one and then updates the callableReference in the JDKInvocationHandler

        ConversationManager conversationManager = ((RuntimeWireImpl)wire).getConversationManager();
        if (conversation == null || conversation.getState() == ConversationState.ENDED) {
            conversation = conversationManager.startConversation(conversationID);
            if (callableReference != null) {
                ((CallableReferenceImpl)callableReference).attachConversation(conversation);
            }
        }

As far as I can see, the JDKInvocationHandler instances all share the same callable reference (passed in at construction time) so they all end up referring to the same instance of BService.

As an experiment, I commented out the following lines and my new itest runs. However, most of the call back itests then do not run.

        // if (callableReference != null) {
        //     ((CallableReferenceImpl)callableReference).attachConversation(conversation);


This change was introduced in SVN revision 575101.

http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/core/src/main/java/org/apache/tuscany/sca/core/invocation/JDKInvocationHandler.java?r1=574648&r2=575101&sortby=date&diff_format=h




Looking in the JDKInvocationHandler, there is existing code for cloning the RuntimeWire in the init() method. However, we do not currently clone the CallableReference.



As a experement, I wanted to clone the CallableReference passed in to the constructor of the JDKInvocationHandler. However, the ServiceReferenceImpl and CallbackWireObjectFactory classes do not implement clone().

I tried a quick and dirty HACK that clones the CallableReference passed into the constructor of the JDKInvocationHandler using reflection, etc. Once the CalalbleReference has been cloned, both my new itest and the callback itests function.

I've attached the patch for the quick and dirty hack. Please don't apply to the source tree :-)


In summary, it looks like we need to:

   * clone the CallableReference when constructing the JDKInvocationHandler.
   * Make the CallableReference cloneable


> Conversational Component referring to another Conversational Component always uses the same instance
> ----------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-1909
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1909
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Core Runtime
>            Reporter: Mark Combellack
>             Fix For: Java-SCA-Next
>
>
> I've run into a problem with two conversational Services. Consider the following scenario:
> AService
>   * Has member variable called state
>   * Has reference to BService
>   * Has set/getState method for setting state on A
>   * Has set/getStateOnB method for setting state on B
> BService
>   * Has member variable called state
> Calling SCADomain.getService(AService) twice, I am expecting to get:
>      AService_1 -> BService_1
> and  AService_2 -> BService_2
> However, I am getting:
>      AService_1 -> BService_1
> and  AService_2 -> BService_1
> i.e a second instance of BService is not being created.
> The first time I get a new instance of AService, a new instance of BService is created.
> The second time I get a new instance of AService, the original BService instance is shared.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org