[
https://issues.apache.org/jira/browse/ACCUMULO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16029466#comment-16029466
]
Michael Miller commented on ACCUMULO-4642:
------------------------------------------
bq. However, I think we can get there incrementally, by starting with
eliminating the SystemConfiguration.getInstance() method.
Are you referring to the AccumuloConfiguration object returned from a call to
ServerConfigurationFactory.getSystemConfiguration() ? I can't find any
SystemConfiguration class...
> Remove SystemConfiguration.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: Christopher Tubbs
> 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 SystemConfiguration.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 SystemConfiguration.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)
