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&data=04%7C01%7Cdasmith%40vmware.com%7C1eb01e77f0694a3b830e08d874f46868%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637387940356374371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o7G%2FGj0tkLvBhf4eSCBLA9GzSK0p%2BsjP4fplWJJNNjs%3D&reserved=0 Please add all comments to the RFC to this email for tracking and discussion. --Udo