It might be better to hang things off InternalCache rather than create a new 
singleton. The cache is already a singleton, but we've been working on removing 
that by plumbing the cache everywhere. The cache is effectively our context 
object, and once we've finished removing calls to Cache.getInstance we will 
have a context object that is not a singleton.

As Jens mentioned, the cache already has the concept of CacheServices that can 
be retrieved using methods similar to what you listened in this RFC - eg 
InternalCache.getService(Class clazz).

Can we reuse/generalize/extend this existing service concept for your case?

-Dan
________________________________
From: Jens Deppe <jde...@vmware.com>
Sent: Tuesday, October 20, 2020 5:33 AM
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: Re: [DISCUSS] ServiceRegistry RFC

Hi Udo,

Is the intention of this to replace (and extend) what we're doing with the 
traditional service loading mechanism today? i.e. how we're loading everything 
that extends CacheService (for example HttpService, LuceneService, 
GeodeRedisService, etc.).

Thanks
--jens



On 10/15/20, 7:25 PM, "Udo Kohlmeyer" <u...@vmware.com> wrote:

    Hi there Apache Geode Devs.

    Please find attached an RFC for the introduction of a ServiceRegistry into 
Apache Geode.

    
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FServiceRegistry&amp;data=04%7C01%7Cdasmith%40vmware.com%7C1eb01e77f0694a3b830e08d874f46868%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637387940356374371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=o7G%2FGj0tkLvBhf4eSCBLA9GzSK0p%2BsjP4fplWJJNNjs%3D&amp;reserved=0

    Please add all comments to the RFC to this email for tracking and 
discussion.

    --Udo

Reply via email to