>
> But we should probably create another thread to talk about it to keep this
> one focused on the singletons discussion.
>
+1
How far can we go down the path of cleaning up Singletons without having a
> DI framework in the mix?
We can do DI without a framework, by just passing the dependencie
+1 to moving the "OOTB" discussion onto another thread. Very
distracting, interjecting another topic, into a completely not related
email thread.
MAYBE, there could be a list of ootb functions that the community would
like to support/write. This should be done on the Apache Geode Wiki.
On 5
+1 for Geode functions as well.
Back on the day, I've talked with Barry about it and we got a few basic
ones into this repository.
https://github.com/markito/geode-functions
But we should probably create another thread to talk about it to keep this
one focused on the singletons discussion.
On T
> On May 25, 2017, at 7:55 AM, Udo Kohlmeyer wrote:
>
> @Kirk, I think your approach to reduce the number of singleton access is
> good. I agree and believe that any operational invocation (Function,Command,
> DistributionMessage,etc...) should provide a mechanism to be able to access
> all r
@Kirk, I think your approach to reduce the number of singleton access is
good. I agree and believe that any operational invocation
(Function,Command, DistributionMessage,etc...) should provide a
mechanism to be able to access all relevant all contextual information
required to execute the task
+1 to utility functions
*Wes Williams | Pivotal Advisory **Data Engineer*
781.606.0325
http://pivotal.io/big-data/pivotal-gemfire
On Wed, May 24, 2017 at 4:59 PM, John Blum wrote:
> On a side but related note, it would be nice if Geode had the notion of
> useful, "canned" Functions provided OOT
On a side but related note, it would be nice if Geode had the notion of
useful, "canned" Functions provided OOTB. Some of the *Gfsh* functions
would be quite useful for applications in fact, or particularly for
framework/tools to use as well. Sometime ago I sent a list of Functions I
thought woul
Thanks for pointing out that DistributionManager is internal -- I forgot
about that. I'm primarily concerned with internal Functions, such as those
for GFSH commands, so maybe an internal version of FunctionContext which
exposes more would be good for those.
On Wed, May 24, 2017 at 11:39 AM, Darre
FunctionContext is an external interface so it can not expose internal
interfaces like DistributionManager.
But it could expose Cache. DistributedSystem is external so you could have
it exposed from FunctionContext but it is already exposed from Cache.
SecurityService is also internal.
Are you thin
I've been digging through our code with close attention to the singletons.
I believe the majority of singletons in Geode exist for two main reasons:
1) Insufficient context or lack of service lookup for Function,
DistributionMessage and (Client)Command implementations.
2) Poor OO design. This is
10 matches
Mail list logo
