Hi Clément, We ended up doing this via ServiceFactory.
A service is either “tenant-aware” (meaning that the tenant logic is built into the service), or more commonly “tenant-unaware” (meaning that it’s like you write below: the service has no knowledge of the tenant). For those that are tenant-aware, we only need one instance (assuming it is a singleton). For those that are not tenant-aware, we need once instance per tenant. All we need to do for a tenant-aware service is add the “factory” property to the component. The FactoryService listens for both tenants and tenant-aware services, and will instantiate a tenant-aware service as required. This allows us to dynamically adapt if a new tenant is registered. This approach has also allowed us to customize services for a specific tenant as required, which was an unexpected bonus. All services that can be shared are shared, which means that I think (have not actually calculated) that we are using computing resources efficiently. In any case, this has been working well for us so far. Cheers, =David > On Jul 2, 2018, at 2:11, Clément Delgrange via osgi-dev > <osgi-dev@mail.osgi.org> wrote: > > Hi, > > What is the way to achieve multi-tenancy with OSGI service. I would like to > design my API without a tenant context per method to concentrate on the > functional part, but also have an OSGI instance which could be scaled up. I > was thinking to let the service implementation decides if the service can be > shared between multiple tenants or not, and in this later case rely on a > standard way to bound service instances specifically for a tenant. Does > configuration admin can help with this? > For example, a service could be configured with multiple PIDs, one for shared > configuration and one factory configuration for tenant specific configuration > and then filter references in component, does that could work? Is there some > good practice for multi tenancy in OSGI? > > Thanks, > Clément. > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
