[
https://issues.apache.org/jira/browse/ARTEMIS-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489683#comment-16489683
]
Christopher L. Shannon commented on ARTEMIS-1888:
-------------------------------------------------
Well I'm not sure how many people are using app server JNDI but this order
doesn't make any sense to me for most use cases. In my case it is causing
issues with migration because I have some use cases where default SSL settings
are set on the JVM but sometimes a different setting (maybe a different
keystore or whatever) is set specifically on a new ActiveMQConnection factory
and it gets completely ignored and overriden by the JVM setting.
The order of precedence should be set up so that the most specific way of
setting the value is the highest priority otherwise you lose the ability to
configure different settings per connection factory (as in this case). Which
is why the most sensible order is:
# transport configuration
# ActiveMQ specific system property
# javax.ssl system property
# defaults
I would prefer to just change the order by default as the current order makes
no sense to me but if not then there at least needs to be some other way to set
the SSL settings on a connection factory that don't get blown away by system
settings (even if that means a new flag or something)
> 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)