[
https://issues.apache.org/jira/browse/CASSANDRA-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939409#comment-13939409
]
Benedict commented on CASSANDRA-6881:
-------------------------------------
In principle it's a fine idea, but it will probably be a painful job. There are
4.5k occurences of "static final" in the code base. Not all of them will need
to be modified, but many of them will, and all will need to be checked. I'm
certainly not keen to try :)
bq. This ticket is really about classloaders and that stuff.
Do you mean _not_ "about classloaders and that stuff"?
> Replace static singletons potentially using dependency injection
> ----------------------------------------------------------------
>
> Key: CASSANDRA-6881
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6881
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Edward Capriolo
> Assignee: Edward Capriolo
>
> I have noticed several places in the cassandra codebase where
> unit,functional, and end-to-end testing is made more difficult due to the
> pattern of using singleton objects with static initialization.
> An example is StorageProxy
> {code}static final boolean OPTIMIZE_LOCAL_REQUESTS = true; // set to false to
> test messagingservice path on single node
> {code}
> There is no coverage for this. It turns out to be very difficult to test for
> a variety of reasons. Mostly that everything it interacts with is hidden
> behind other static singletons.
> The goal here would be to remove static stuff, have have a context, (spring,
> guice, or do out own). For the majority of things stop accessing them through
> static singleton, instead pass the objects (DatabaseDescriptor, Storageproxy)
> around or get them from the context. I think this will make a clearer API and
> allow us to provide better coverage on features that cross cut the
> components. It will *also* provide us better isolation for things like
> triggers/ udfs/ as they wont be able to acquire references to things they
> should not be able to.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
