You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by "Kezhu Wang (Jira)" <ji...@apache.org> on 2023/08/08 03:28:00 UTC
[jira] [Closed] (CURATOR-152) NamespaceFacade does not provide access to underyling client
[ 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)