[
https://issues.apache.org/jira/browse/ZOOKEEPER-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Nauroth resolved ZOOKEEPER-2451.
--------------------------------------
Resolution: Duplicate
Hello [~sershe].
I believe your concerns are addressed in ZOOKEEPER-2139, which has a patch
committed for the 3.5.2-alpha release candidate that I'm about to create
shortly. That patch allows for more fine-grained configuration of the client
without needing to rely on global JVM properties.
I'll resolve this as a duplicate. (If I misunderstood, please feel free to
reopen.)
> do not make use of system properties for security configuration
> ---------------------------------------------------------------
>
> Key: ZOOKEEPER-2451
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2451
> Project: ZooKeeper
> Issue Type: Bug
> Reporter: Sergey Shelukhin
>
> Is there (or could there be) a way to set up security for ZK client that
> doesn't involve calls like {noformat}
> System.setProperty(ZooKeeperSaslClient.LOGIN_CONTEXT_NAME_KEY,
> SASL_LOGIN_CONTEXT_NAME);
> {noformat}?
> I was looking at an unrelated security configuration issue and stumbled upon
> this pattern; we use (at least) 2 ZK connections from the same process, that
> (for now) use the same config but different context names, one of which is in
> a library out of our control. Unless I'm missing something with this pattern
> it seems extremely brittle. Or unless there's an alternative approach
> already; if there is, hadoop-common and hive don't use it atm, old approach
> seems prevalent.
> There should be an approach that is at least slightly more solid, like say
> public globals... maybe even threadlocals!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
