You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Simon Laws (Created) (JIRA)" <de...@tuscany.apache.org> on 2012/02/07 14:04:59 UTC

[jira] [Created] (TUSCANY-4011) Callback binding gets overriden and other issues

Callback binding gets overriden and other issues
------------------------------------------------

                 Key: TUSCANY-4011
                 URL: https://issues.apache.org/jira/browse/TUSCANY-4011
             Project: Tuscany
          Issue Type: Bug
          Components: SCA Java Runtime
    Affects Versions: Java-SCA-2.0-Beta3
         Environment: All
            Reporter: Simon Laws
             Fix For: Java-SCA-2.0


I've noticed that any callback binding configuration provided in the SCDL is not present when the binding is used. It's because the binding is overridden by the callback endpoint created by the service binding. 

Only the URI is required so we can take this out of the binding created by the service binding and set it on the callback binding.

In trying to work out what was going on here I noticed a couple of other things that I'd like to improve:

- The code here is complicated by the thought that a single CallbackServiceReference might be used to contact multiple callback endpoints. This is no longer the case. For STATELESS components a new set of callback proxies (and hence CallbackServiceReference) is created for each new incoming message, because that's what happens with STATELESS components. For COMPOSITE components a new callback proxy is created for each call through the RequestContext object. Hence there is always a new CallbackServiceReference instance for each incoming call and related callback target. I believe the current complexity can be removed so that the CallbackServiceReference only every refers to one callback endpoint

- There is an opportunity for further optimization if a binding is prepared to be responsible for resetting it's reference target address in the callback case. For example, if we provide a field in the forward message where a service binding can place the callback URI then we can remove the EPR clone in the CallbackServiceReference and have the callback reference binding take the target address out of the callback message. This need a bit of thought so I'll open a separate JIRA for it when I get to looking at it. 



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Closed] (TUSCANY-4011) Callback binding gets overriden and other issues

Posted by "Simon Laws (Closed) (JIRA)" <de...@tuscany.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Simon Laws closed TUSCANY-4011.
-------------------------------

    Resolution: Fixed

Closing as change was committed at rev1242412
                
> Callback binding gets overriden and other issues
> ------------------------------------------------
>
>                 Key: TUSCANY-4011
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-4011
>             Project: Tuscany
>          Issue Type: Bug
>          Components: SCA Java Runtime
>    Affects Versions: Java-SCA-2.0-Beta3
>         Environment: All
>            Reporter: Simon Laws
>             Fix For: Java-SCA-2.0
>
>
> I've noticed that any callback binding configuration provided in the SCDL is not present when the binding is used. It's because the binding is overridden by the callback endpoint created by the service binding. 
> Only the URI is required so we can take this out of the binding created by the service binding and set it on the callback binding.
> In trying to work out what was going on here I noticed a couple of other things that I'd like to improve:
> - The code here is complicated by the thought that a single CallbackServiceReference might be used to contact multiple callback endpoints. This is no longer the case. For STATELESS components a new set of callback proxies (and hence CallbackServiceReference) is created for each new incoming message, because that's what happens with STATELESS components. For COMPOSITE components a new callback proxy is created for each call through the RequestContext object. Hence there is always a new CallbackServiceReference instance for each incoming call and related callback target. I believe the current complexity can be removed so that the CallbackServiceReference only every refers to one callback endpoint
> - There is an opportunity for further optimization if a binding is prepared to be responsible for resetting it's reference target address in the callback case. For example, if we provide a field in the forward message where a service binding can place the callback URI then we can remove the EPR clone in the CallbackServiceReference and have the callback reference binding take the target address out of the callback message. This need a bit of thought so I'll open a separate JIRA for it when I get to looking at it. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira