[
https://issues.apache.org/jira/browse/CURATOR-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14549348#comment-14549348
]
Gregory Chanan commented on CURATOR-221:
----------------------------------------
I don't necessarily think the behavior is unreasonable. For example, if those
parent nodes already existed, I probably wouldn't want them to have their ACLs
changed.
That said, it was surprising to me that doing operations on CuratorFramework
with an ACLProvider specified resulted in nodes being created that didn't use
the ACLProvider. Perhaps there could be some configuration about what to do
wrt ACLs for implicitly created parent nodes in Namespaces? e.g.
usingNamespace(path, boolean useACLsIfCreatingParents) or
usingNamespace(path).useACLsIfCreatingParents(true)
bq. Can you create the namespace root separately
Yes, although in my case it's a bit complicated. If you look at HADOOP-11973,
to keep the external vs internal client impl similar, I want to initialize the
final CuratorFramework object in the constructor, which means I want to use the
namespace-aware version. So, I could create the nodes before I call
usingNamespace, but then I have to deal with exception handling, which I don't
want to do in the constructor. So essentially I have to do:
- call usingNamespace(ns) in the constructor
- in startThreads, call usingNamespace(null) and then create the parents
manually.
That seems clunkier than specifying what I want to happen with the parents on
the namespace itself.
> ACLProvider is not respected on parent nodes after calling
> CuratorFramework.usingNamespace
> ------------------------------------------------------------------------------------------
>
> Key: CURATOR-221
> URL: https://issues.apache.org/jira/browse/CURATOR-221
> Project: Apache Curator
> Issue Type: Bug
> Components: Framework
> Affects Versions: 2.7.1
> Reporter: Gregory Chanan
>
> See HADOOP-11973 for some background information.
> Here's a high level overview of the issue I'm seeing:
> 1) I create a CuratorFramework with a non-default ACLProvider
> 2) I call framework.usingNamespace("/solr/zkdtsm") on the curator framework
> 3) I do some action, like starting a new SharedCount on a subnode of the
> namespace /testPath/ZKDTSMRoot/ZKDTSMSeqNumRoot
> Result: the tree is created, but neither /solr nor /solr/zkdtsm have ACLs,
> while /testPath/ZKDTSMRoot/ZKDTSMSeqNumRoot does. I would expect all those
> nodes would have ACLs because I only performed zookeeper actions on a
> CuratorFramework with an ACLProvider specified.
> This seems to happen because NamespaceImpl does not save the ACLProvider, see
> this line:
> https://github.com/apache/curator/blob/7f2098654a26e2f593801a586ce68300f54abf15/curator-framework/src/main/java/org/apache/curator/framework/imps/NamespaceImpl.java#L47
> Then, when an action is performed on the namespace, fixForNamespace is called:
> https://github.com/apache/curator/blob/7f2098654a26e2f593801a586ce68300f54abf15/curator-framework/src/main/java/org/apache/curator/framework/imps/NamespaceImpl.java#L74
> resulting in the parents being created without an ACL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
