[ 
https://issues.apache.org/jira/browse/ARTEMIS-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489582#comment-16489582
 ] 

Christopher L. Shannon commented on ARTEMIS-1888:
-------------------------------------------------

I should add that I think this patch is ok because there is now the flag 
"useDefaultSslContext" that can be set which I think fixes the original problem 
that HORNETQ-680 addressed.

> 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)

Reply via email to