[
https://issues.apache.org/jira/browse/ARTEMIS-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489659#comment-16489659
]
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: 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 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)
