[
https://issues.apache.org/jira/browse/CXF-7840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16620392#comment-16620392
]
Freeman Fang commented on CXF-7840:
-----------------------------------
Hi James,
This is expected behavior in CXF. When cxf detects endpoint address change, it
will recreate another conduit, to ensure message can be sent to the correct
different destination.
So in your testcase, you actually can revise a little bit. put this line
{code}
provider.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
ENDPOINT_ADDRESS);
{code}
Before
{code}
HTTPConduit httpConduit = setupTLS(port);
{code}
Then you should be all set.
Freeman
> TLSClientParameters are erased when changing the endpoint address
> -----------------------------------------------------------------
>
> Key: CXF-7840
> URL: https://issues.apache.org/jira/browse/CXF-7840
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 3.2.4, 3.2.6
> Environment: Windows/Windows server. CXF 3.2.4. Java 1.8.
> Reporter: James Bailey
> Assignee: Freeman Fang
> Priority: Major
> Attachments: CXFTLSTestCase.zip
>
>
> I have a set of WSDLs that I cannot change. They do not have the correct
> endpoint address for the server but that is easily changed by using
> provider.getRequestContext.put(ENDPOINT_ADDRESS_PROPERTY...
> This works fine as long as the server is not using a self signed certificate.
> But when I add the code to trust the certificate and also change the endpoint
> address, the TLSClientParameters are ignored because the conduit is
> reconfigured and replaced with a new conduit without the parameters. If I run
> once in a try block and then update the conduit with the TLSClientParameters
> and run a second time, this works.
> I've included a test case to show the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
