Use InternalCache instead of GemFireCacheImpl

[Kirk Lund <kl...@apache.org>]

I just merged in a big refactoring which changes classes that were using
GemFireCacheImpl to using InternalCache.

InternalCache is an interface representing the internal view of Cache which
exposes all the operations that aren't exposed in the User API of Cache or
GemFireCache. InternalCache and GemFireCacheImpl are still too big and need
to be broken out but this is one step in refactoring.

If you need to create or change a class to use GemFireCacheImpl, please
make that class depend on InternalCache instead. Also, please pass the
InternalCache instance to the constructor instead of reaching out from the
class to call GemFireCacheImpl.getInstance or CacheFactory.getAnyInstance.
This will reduce the number of classes we need to change in further
refactoring to reduce the use of these singleton accessors.

If you encounter any merge conflicts caused by my commit, please let me
know and I'll do what I can to help.

Thanks,
Kirk

Re: Use InternalCache instead of GemFireCacheImpl

[Galen M O'Sullivan <go...@pivotal.io>]

Thanks for making this critical refactoring work happen, Kirk! The day of
two Caches in a single JVM seems just a little bit closer now.

On Mon, May 15, 2017 at 1:31 PM, Dan Smith <ds...@pivotal.io> wrote:

> +googol - you're awesome Kirk, thanks for taking this on!
>
> -Dan
>
> On Mon, May 15, 2017 at 1:03 PM, Kirk Lund <kl...@apache.org> wrote:
>
> > I just merged in a big refactoring which changes classes that were using
> > GemFireCacheImpl to using InternalCache.
> >
> > InternalCache is an interface representing the internal view of Cache
> which
> > exposes all the operations that aren't exposed in the User API of Cache
> or
> > GemFireCache. InternalCache and GemFireCacheImpl are still too big and
> need
> > to be broken out but this is one step in refactoring.
> >
> > If you need to create or change a class to use GemFireCacheImpl, please
> > make that class depend on InternalCache instead. Also, please pass the
> > InternalCache instance to the constructor instead of reaching out from
> the
> > class to call GemFireCacheImpl.getInstance or
> CacheFactory.getAnyInstance.
> > This will reduce the number of classes we need to change in further
> > refactoring to reduce the use of these singleton accessors.
> >
> > If you encounter any merge conflicts caused by my commit, please let me
> > know and I'll do what I can to help.
> >
> > Thanks,
> > Kirk
> >
>

Re: Use InternalCache instead of GemFireCacheImpl

[Dan Smith <ds...@pivotal.io>]

+googol - you're awesome Kirk, thanks for taking this on!

-Dan

On Mon, May 15, 2017 at 1:03 PM, Kirk Lund <kl...@apache.org> wrote:

> I just merged in a big refactoring which changes classes that were using
> GemFireCacheImpl to using InternalCache.
>
> InternalCache is an interface representing the internal view of Cache which
> exposes all the operations that aren't exposed in the User API of Cache or
> GemFireCache. InternalCache and GemFireCacheImpl are still too big and need
> to be broken out but this is one step in refactoring.
>
> If you need to create or change a class to use GemFireCacheImpl, please
> make that class depend on InternalCache instead. Also, please pass the
> InternalCache instance to the constructor instead of reaching out from the
> class to call GemFireCacheImpl.getInstance or CacheFactory.getAnyInstance.
> This will reduce the number of classes we need to change in further
> refactoring to reduce the use of these singleton accessors.
>
> If you encounter any merge conflicts caused by my commit, please let me
> know and I'll do what I can to help.
>
> Thanks,
> Kirk
>

Re: Use InternalCache instead of GemFireCacheImpl

[Udo Kohlmeyer <uk...@pivotal.io>]

1) I think this discussion should be on another thread

2) I don't know if this is something that could be that easily changed 
per region.


On 5/15/17 16:40, Michael Stolz wrote:
> While we are going down this path, could read-serialized be a Region
> property?
>
> --
> Mike Stolz
> Principal Engineer - Gemfire Product Manager
> Mobile: 631-835-4771
>
> On May 15, 2017 7:22 PM, "Jacob Barrett" <jb...@pivotal.io> wrote:
>
>> This is an awesome step forward!
>>
>> We are getting close to committing similar refactoring on the C++ client to
>> move away from globals too.
>>
>> Death to globals!
>>
>> -Jake
>>
>> On Mon, May 15, 2017 at 1:03 PM Kirk Lund <kl...@apache.org> wrote:
>>
>>> I just merged in a big refactoring which changes classes that were using
>>> GemFireCacheImpl to using InternalCache.
>>>
>>> InternalCache is an interface representing the internal view of Cache
>> which
>>> exposes all the operations that aren't exposed in the User API of Cache
>> or
>>> GemFireCache. InternalCache and GemFireCacheImpl are still too big and
>> need
>>> to be broken out but this is one step in refactoring.
>>>
>>> If you need to create or change a class to use GemFireCacheImpl, please
>>> make that class depend on InternalCache instead. Also, please pass the
>>> InternalCache instance to the constructor instead of reaching out from
>> the
>>> class to call GemFireCacheImpl.getInstance or
>> CacheFactory.getAnyInstance.
>>> This will reduce the number of classes we need to change in further
>>> refactoring to reduce the use of these singleton accessors.
>>>
>>> If you encounter any merge conflicts caused by my commit, please let me
>>> know and I'll do what I can to help.
>>>
>>> Thanks,
>>> Kirk
>>>

Re: Use InternalCache instead of GemFireCacheImpl

[Michael Stolz <ms...@pivotal.io>]

While we are going down this path, could read-serialized be a Region
property?

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771

On May 15, 2017 7:22 PM, "Jacob Barrett" <jb...@pivotal.io> wrote:

> This is an awesome step forward!
>
> We are getting close to committing similar refactoring on the C++ client to
> move away from globals too.
>
> Death to globals!
>
> -Jake
>
> On Mon, May 15, 2017 at 1:03 PM Kirk Lund <kl...@apache.org> wrote:
>
> > I just merged in a big refactoring which changes classes that were using
> > GemFireCacheImpl to using InternalCache.
> >
> > InternalCache is an interface representing the internal view of Cache
> which
> > exposes all the operations that aren't exposed in the User API of Cache
> or
> > GemFireCache. InternalCache and GemFireCacheImpl are still too big and
> need
> > to be broken out but this is one step in refactoring.
> >
> > If you need to create or change a class to use GemFireCacheImpl, please
> > make that class depend on InternalCache instead. Also, please pass the
> > InternalCache instance to the constructor instead of reaching out from
> the
> > class to call GemFireCacheImpl.getInstance or
> CacheFactory.getAnyInstance.
> > This will reduce the number of classes we need to change in further
> > refactoring to reduce the use of these singleton accessors.
> >
> > If you encounter any merge conflicts caused by my commit, please let me
> > know and I'll do what I can to help.
> >
> > Thanks,
> > Kirk
> >
>

Re: Use InternalCache instead of GemFireCacheImpl

[Jacob Barrett <jb...@pivotal.io>]

This is an awesome step forward!

We are getting close to committing similar refactoring on the C++ client to
move away from globals too.

Death to globals!

-Jake

On Mon, May 15, 2017 at 1:03 PM Kirk Lund <kl...@apache.org> wrote:

> I just merged in a big refactoring which changes classes that were using
> GemFireCacheImpl to using InternalCache.
>
> InternalCache is an interface representing the internal view of Cache which
> exposes all the operations that aren't exposed in the User API of Cache or
> GemFireCache. InternalCache and GemFireCacheImpl are still too big and need
> to be broken out but this is one step in refactoring.
>
> If you need to create or change a class to use GemFireCacheImpl, please
> make that class depend on InternalCache instead. Also, please pass the
> InternalCache instance to the constructor instead of reaching out from the
> class to call GemFireCacheImpl.getInstance or CacheFactory.getAnyInstance.
> This will reduce the number of classes we need to change in further
> refactoring to reduce the use of these singleton accessors.
>
> If you encounter any merge conflicts caused by my commit, please let me
> know and I'll do what I can to help.
>
> Thanks,
> Kirk
>