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