You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Andrei Shakirin (Created) (JIRA)" <ji...@apache.org> on 2011/12/14 14:01:30 UTC
[jira] [Created] (CXF-3976)
SoapTransportFactory.getConduit(EndpointInfo ei, EndpointReferenceType
target) ignors second parameter
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
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.
--
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] [Updated] (CXF-3976)
SoapTransportFactory.getConduit(EndpointInfo ei, EndpointReferenceType
target) ignors second parameter
Posted by "Andrei Shakirin (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrei Shakirin updated CXF-3976:
---------------------------------
Attachment: SoapTransportFactory.patch
Patch
> 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:
> 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.
--
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] [Updated] (CXF-3976)
SoapTransportFactory.getConduit(EndpointInfo ei, EndpointReferenceType
target) ignores second parameter
Posted by "Andrei Shakirin (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrei Shakirin updated CXF-3976:
---------------------------------
Summary: SoapTransportFactory.getConduit(EndpointInfo ei, EndpointReferenceType target) ignores second parameter (was: SoapTransportFactory.getConduit(EndpointInfo ei, EndpointReferenceType target) ignors second parameter)
> SoapTransportFactory.getConduit(EndpointInfo ei, EndpointReferenceType target) ignores 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:
> <pre>
> 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);
> }
> </pre>
> 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
[jira] [Updated] (CXF-3976)
SoapTransportFactory.getConduit(EndpointInfo ei, EndpointReferenceType
target) ignors second parameter
Posted by "Andrei Shakirin (Updated) (JIRA)" <ji...@apache.org>.
[ 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:
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.
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:
> 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.
--
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] [Updated] (CXF-3976)
SoapTransportFactory.getConduit(EndpointInfo ei, EndpointReferenceType
target) ignores second parameter
Posted by "Daniel Kulp (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp 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:java}
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:
<pre>
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);
}
</pre>
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) ignores 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:java}
> 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
[jira] [Resolved] (CXF-3976)
SoapTransportFactory.getConduit(EndpointInfo ei, EndpointReferenceType
target) ignores second parameter
Posted by "Daniel Kulp (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-3976.
------------------------------
Resolution: Fixed
Fix Version/s: 2.4.6
2.5.1
Assignee: Daniel Kulp
> SoapTransportFactory.getConduit(EndpointInfo ei, EndpointReferenceType target) ignores 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
> Assignee: Daniel Kulp
> Fix For: 2.5.1, 2.4.6
>
> 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:java}
> 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
[jira] [Updated] (CXF-3976)
SoapTransportFactory.getConduit(EndpointInfo ei, EndpointReferenceType
target) ignors second parameter
Posted by "Andrei Shakirin (Updated) (JIRA)" <ji...@apache.org>.
[ 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:
<pre>
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);
}
</pre>
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:
<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.
> 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:
> <pre>
> 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);
> }
> </pre>
> 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
[jira] [Updated] (CXF-3976)
SoapTransportFactory.getConduit(EndpointInfo ei, EndpointReferenceType
target) ignors second parameter
Posted by "Andrei Shakirin (Updated) (JIRA)" <ji...@apache.org>.
[ 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