[
https://issues.apache.org/jira/browse/CURATOR-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kezhu Wang closed CURATOR-152.
------------------------------
Resolution: Information Provided
{quote}
This is impractical for the case where NamespaceFacade is being used as the
only CuratorFramework available to an application.
{quote}
I don't know which curator version this jira targeting. But for now,
{{CuratorFrameworkFactory.Builder::namespace}} can specify initial namespace
for {{CuratorFramework}}. Basically, you don't have to resort to
{{CuratorFramework::usingNamespace}} if there is only one namespace.
> NamespaceFacade does not provide access to underyling client
> ------------------------------------------------------------
>
> Key: CURATOR-152
> URL: https://issues.apache.org/jira/browse/CURATOR-152
> Project: Apache Curator
> Issue Type: Improvement
> Components: Framework
> Reporter: Whitney Sorenson
> Priority: Minor
>
> NamespaceFacade throws UnsupportedOperationException on close() and start().
> This is impractical for the case where NamespaceFacade is being used as the
> only CuratorFramework available to an application. Clients are left to either:
> - Make a separate binding for underlying curator framework
> - Use reflection to access underlying client
> - Reimplement Namespace functionality in their own code
> None of these are ideal or necessary. The NamespaceFacade should allow close
> to be called on the underlying client or should allow access to the
> underlying client for this type of use case. Since it previously threw an
> exception, proxying the close call to the underlying client would not break
> existing users.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
