Hi,

I faced the problem in custom conduit selector scenario.

Use case: custom conduit selector (extends AbstractConduitSelector) resolves 
endpoints dynamically (using external ServiceRegistry).

When address is resolved, resolved address cannot be set to 
AbstractConduitSelector.endpoint, because different concurrent consumers using 
the same configuration can resolve endpoint differently.
Therefore address is just set to the message: 
message.set(Message.ENDPOINT_ADDRESS, resolvedAddress)
In this case addresses in message:  message.get(Message.ENDPOINT_ADDRESS) and 
in endpoint: AbstractConduitSelector.endpoint.getEndpointInfo().getAddress() 
are different.

AbstractConduitSelector check it and prepares EndpointReferenceType for this 
case:
                       String add = 
(String)message.get(Message.ENDPOINT_ADDRESS);
                        if (StringUtils.isEmpty(add)
                            || add.equals(ei.getAddress())) {
                            replaceEndpointAddressPropertyIfNeeded(message, 
add);
                            selectedConduit = conduitInitiator.getConduit(ei);
                        } else {
                            EndpointReferenceType epr = new 
EndpointReferenceType();
                            AttributedURIType ad = new AttributedURIType();
                            ad.setValue(add);
                            epr.setAddress(ad);
                            selectedConduit = conduitInitiator.getConduit(ei, 
epr);
                        }

Problem: unfortunately SoapTransportFactory.getConduit(EndpointInfo ei, 
EndpointReferenceType target) ignores second parameter and calls 
SoapTransportFactory.getConduit(EndpointInfo ei). In my case it causes wrong 
Conduit resolving.

Proposal: update SoapTransportFactory.getConduit() in way that it uses address 
in EndpointReferenceType if it is provided.

If proposal my is ok, I will prepare JIRA case with patch.

Regards,
Andrei.

Reply via email to