Christopher L. Shannon created ARTEMIS-1888:
-----------------------------------------------
Summary: Core client SSL property precedence should prefer local
configuration options
Key: ARTEMIS-1888
URL: https://issues.apache.org/jira/browse/ARTEMIS-1888
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.6.0
Reporter: Christopher L. Shannon
Assignee: Christopher L. Shannon
Fix For: 2.7.0
When doing some testing I noticed that the order of precedence for setting SSL
properties inside the core client NettyConnector is a bit backwards. Any
javax.ssl property takes ultimate precedence and overrides a property that is
set locally in the configuration map. This doesn't make sense to me and makes
it so you can't override settings (ie in the same JVM use have two different
connections use different SSL settings if a global javax.ssl property is
already set). There is a comment that mentions HORNETQ-680 as where this
change was made so. I'm not sure what side effects this will have but I think
this behavior is wrong and doesn't match how the 5.x client works.
I think that the order of precedence should be changed to the following when
looking for SSL properties:
# First check the transport configuration for a property setting
# If not set then next check for an ActiveMQ specific JVM property
# If not set then check for a javax.ssl JVM wide property
# Lastly, if still not set then use a default value (in the case of the
keystore or truststore provider)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
