cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward Capriolo (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-6881) Replace static singletons potentially using dependency injection
Date Sat, 05 Apr 2014 15:41:18 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13961132#comment-13961132
] 

Edward Capriolo edited comment on CASSANDRA-6881 at 4/5/14 3:40 PM:
--------------------------------------------------------------------

I have played with this for a little bit now. I started by simple removing the static singleton
on StorageProxy, creating a context and then fixing everything that turns read in my IDE.
This does not work our well because changes start cascading and, more classes turn read, and
you make more changes, and so on. So I am going to start a new approach.

In the process though I noticed many "leaf" classes. IE verbs that only need StorageProxy,
CQL classes that change schema that only use storage service.I have a new plan. Ripping the
band aid and ending up with clean API's is going to be hard, and a very large scary patch.The
best approach is to keep the static singletons for now. However start passing the instance
between classes rather than letting these leaf classes access the singleton. This would probably
result in 5-7 sub tasks, but it would give us a more clean controlled way to re-shape the
APIs in an organic way (rather then a rip the band aid approach). By the time we reach the
end of the tickets most of the classes should no longer be connected by static singletons
and hopefully the final change to remove it entirely will be less scary at that point.


was (Author: appodictic):
I have played with this for a little bit now. I started by simple removing the static singleton
on StorageProxy, creating a context and then fixing everything that turns read in my IDE.
This does not work our well because changes start cascading and, more classes turn read, and
you make more changes, and so on. So I am going to start a new approach.

In the process though I noticed many "leaf" classes. IE verbs that only need StorageProxy,
CQL classes that change schema that only use storage service.I have a new plan. Ripping the
band aid and ending up with clean API's is going to be hard, and a very large scary patch.The
best approach is to keep the static singletons for now. However start passing the instance
between classes rather than letting these leaf classes access the singleton. This would probably
result in 5-7 sub tasks, but it would give us a more clean controlled way to re-shape the
APIs in an organic way (rather then a rip the band aid approach). By the time we reach the
end of the tickets most of the classes should no longer be connected by major static singletons
and hopefully the final change to remove it entirely will be less scary at that point.

> 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)

Mime
View raw message