[
https://issues.apache.org/jira/browse/CXF-3976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Shakirin updated CXF-3976:
---------------------------------
Description:
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:
<code>
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);
}
</code>
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.
Patch is attached.
Regards,
Andrei.
was:
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.
Patch is attached.
Regards,
Andrei.
> SoapTransportFactory.getConduit(EndpointInfo ei, EndpointReferenceType
> target) ignors second parameter
> ------------------------------------------------------------------------------------------------------
>
> Key: CXF-3976
> URL: https://issues.apache.org/jira/browse/CXF-3976
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.5
> Environment: Windows
> Reporter: Andrei Shakirin
> Attachments: SoapTransportFactory.patch
>
>
> 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:
> <code>
> 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);
> }
> </code>
> 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.
> Patch is attached.
> Regards,
> Andrei.
--
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
