Settings on the conduit - if you use code or configuration to
directly manipulate the conduit (like to set TLS settings or similar),
those are not thread safe. The conduit is per-instance and thus those
settings would be shared. Also, if you use the FailoverFeature and
LoadBalanceFeatures, the conduit is replaced on the fly. Thus, settings
set on the conduit could get lost before being used on the setting
For the conduit issues, you COULD install a new ConduitSelector
that uses a thread local or similar. That's a bit complex though.
In my code I set the TLS parameters on the conduit, but in case of a failover, the conduit will replaced on the fly and the new created conduit has lost all my TLS parameters.
FailoverTargetSelector inherits from AbstractConduitSelector
Maybe I can write my own FailoverTargetSelector that sets my TLS parameters in the method createConduit(..) or anywhere else.
It's just a guess or idea.
I'm not really sure if that will work
> JAX-RS Client - Failover does not respect truststore settings
> Key: CXF-8211
> URL: https://issues.apache.org/jira/browse/CXF-8211 > Project: CXF
> Issue Type: Bug
> Components: JAX-RS Security
> Affects Versions: 3.2.1
> Reporter: Stephan Gasser
> Priority: Major
> Attachments: CXF_att_init_jax_rs_client.java
> Setup the client for TLS/SSL (use my own truststore)
> Setup the client for Failover
> * In normal case, the client communicates over TLS/SSL with the server (certificate found in my own truststore)
> * But in the case of a failover, the client use cacerts (???) and not my own configured truststore (-> SSLHandshakeException)
> If I set the 2 properties 'javax.net.ssl.trustStore' and 'javax.net.ssl.trustStorePassword' to my own truststore the TLS/SSL connection to the failover host works as well.
> But this is not the idea, because I configured my own truststore with TLSClientParameters and TrustManagerFactory (with method init(myOwnTruststore)).
This message was sent by Atlassian Jira