cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward Capriolo (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6881) Replace static singletons potentially using dependency injection
Date Tue, 18 Mar 2014 14:57:56 GMT


Edward Capriolo commented on CASSANDRA-6881:

I do not like spring either. We can use juice, something else, or just the concept. But we
should not hate spring just because,,,, its spring..... Think about the problem at large,
StorageProxy requires CFMetaData spring gives us a nice system to construct (String beans),
initialize (init()), destroy( destroy()) and order dependencies. In a test we should be able
to swap out CFMetaData with a mock. We can't do that now easily. Static singleton is a virus,
every new piece also needs to be static singleton, and the process goes on.

> Replace static singletons potentially using dependency injection
> ----------------------------------------------------------------
>                 Key: CASSANDRA-6881
>                 URL:
>             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

View raw message