activemq-issues mailing list archives

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


Justin Bertram commented on ARTEMIS-1888:

Originally the whole point of this was to allow system properties to override what was set
in the connector's SSL configuration because that configuration might have been fetched from
JNDI and therefore might not be appropriate for the client.  If I recall correctly, the order
of precedence was:
 # ActiveMQ specific system property
 # javax.ssl system property
 # transport configuration
 # defaults

Now that Artemis uses a client-side JNDI implementation this order makes less sense because
the connector will always be in the client's control.  However, this order still impacts use-cases
like application servers which do implement client-server JNDI (e.g. Wildfly).

> 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