Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Wed, 31 May 2017 20:04:07 +0000 (UTC)
From: "Michael Miller (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.13074358.1495581711000.335204.1496261047088@Atlassian.JIRA>
In-Reply-To: <JIRA.13074358.1495581711000@Atlassian.JIRA>
References: <JIRA.13074358.1495581711000@Atlassian.JIRA> <JIRA.13074358.1495581711119@jira-lw-us.apache.org>
Subject: [jira] [Assigned] (ACCUMULO-4642) Remove
 ServerConfiguration.getInstance()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 31 May 2017 20:04:11 -0000


     [ https://issues.apache.org/jira/browse/ACCUMULO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Miller reassigned ACCUMULO-4642:
----------------------------------------

    Assignee: Michael Miller  (was: Christopher Tubbs)

> Remove ServerConfiguration.getInstance()
> ----------------------------------------
>
>                 Key: ACCUMULO-4642
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4642
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: server-base
>            Reporter: Christopher Tubbs
>            Assignee: Michael Miller
>            Priority: Minor
>         Attachments: ACCUMULO-4642-initial-draft.patch
>
>
> In working with ACCUMULO-4050, I've realized that we need to do some internal refactoring to get better control over HdfsZooInstance. This would enable better testing (because we could inject a mock Instance more easily, and in more places). It would also allow us to reuse objects without storing them statically in the JVM.
> Fully realizing this would involve a lot of work, moving the static state to a single "context" object constructed on server startup, and shared (in part or in whole) as needed throughout the runtime server code.
> However, I think we can get there incrementally, by starting with eliminating the ServerConfiguration.getInstance() method. This causes SystemConfigurationFactory to also have a getInstance() method, and that means that SystemConfigurationFactory is being used like the context object I describe, but redundantly instead of AccumuloServerContext, or a server-specific subclass.
> Eliminating ServerConfiguration.getInstance() might involve an intermediate step of adding Instance parameters to many methods which currently take only a SystemConfigurationFactory, because components will not be able to get the Instance from that configuration factory any longer. However, even this intermediate step will be progress towards moving to a single shared context object, which provides access to both the Instance and the configuration factory.
> If we can move directly to the context object, that would probably be better, but it would involve a lot more changes, in particular to the way the server code is initialized. Then again, those changes might be good to prioritize anyway, because all our server components seem to initialize differently, and it would be nice to rewrite their bootstrap code to follow the same pattern.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)