[
https://issues.apache.org/jira/browse/ARTEMIS-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489449#comment-16489449
]
ASF GitHub Bot commented on ARTEMIS-1888:
-----------------------------------------
GitHub user cshannon opened a pull request:
https://github.com/apache/activemq-artemis/pull/2109
ARTEMIS-1888 - Fix SSL order of precedence in core client
Local connection SSL settings should be preferred over javax.ssl
settings
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/cshannon/activemq-artemis ARTEMIS-1888
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/2109.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2109
----
commit 6aca83dfe64c661ecb29d07e0676a7698f450293
Author: Christopher L. Shannon (cshannon) <christopher.l.shannon@...>
Date: 2018-05-24T16:04:56Z
ARTEMIS-1888 - Fix SSL order of precedence in core client
Local connection SSL settings should be preferred over javax.ssl
settings
----
> 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
> Priority: Major
> 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)
