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
