I don't think we should go down the path of copying all the runtime
information back into the model.  In this specific case, omitting
explicit callback binding information from the model means that the
implementation runtime can make a choice.  So there is no inconsistency
with the runtime having more information than is explicitly stored in
the model.  A similar case would be a WSDL-less Web Service binding,
which I would expect to keep more information around at runtime than
is explictly stored in the model.  There are probably other cases
as well.

I'd suggest changing the code listed below to use runtime objects
(i.e., the service returned by calling getCallbackService() on the
reference) rather than model objects.

  Simon

Simon Laws wrote:
In Axis2ReferenceBindingProvider constructor there is some code that looks
for the callback associated with the reference, if there is one, to get the
binding. From this it ultimately determines the from address for outgoing
messages.

        // look for a matching callback binding
        WebServiceBinding callbackBinding = null;
        if (reference.getCallback() != null) {
            for (Binding binding : reference.getCallback().getBindings()) {
                if (binding instanceof WebServiceBinding) {
                    // set the first compatible callback binding
                    callbackBinding = (WebServiceBinding)binding;
                    continue;
                }
            }
        }

In the case where the callback information is inferred from the
implementation rather than explicitly included in the SCDL the callback
model object on the reference is incomplete, i.e. there is no binding
information, but the callback service runtime object appears to be complete.
So we either need to ensure that the model is up to date in these situations
or that we go get the required information from the callback service. If it
is generally the case that the model is an accurate reflection of the
current runtime objects then we should make sure the model is updated.

Thoughts?

Regards

Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to