activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <>
Subject [jira] [Commented] (ARTEMIS-1888) Core client SSL property precedence should prefer local configuration options
Date Thu, 24 May 2018 21:00:00 GMT


Timothy Bish commented on ARTEMIS-1888:

The way it currently works is pretty much the exact opposite of how most client's I'm aware
of manage the SSL options and how they are scoped.

> Core client SSL property precedence should prefer local configuration options
> -----------------------------------------------------------------------------
>                 Key: ARTEMIS-1888
>                 URL:
>             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 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

View raw message