> I would have multiple implementations of that service. Even if you would have multiple implementations of that service, you still can bind only one service instance to the corresponding Guice annotation, and this binding is static. The point is, Shindig is not multi-tenant by design so following this approach we will have to make it multi-tenant. That could mean we end up rewriting large parts of the Shindig implementation, or implementing our own OpenSocial container. And Shindig is only one example, we have similar challenges with Wink. This would not be necessary with the ThreadLocal approach.
Regards, Ivo -----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Marcel Offermans Sent: donderdag 6 januari 2011 10:54 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] Multi-tenancy (and more) design On 6 Jan 2011, at 10:22 , Ivo Ladage-van Doorn wrote: > You're missing the point as I tried to explain in these issues; you assume > that any method that needs to do something with a tenant eventually has > access to the tenant.id, via a HTTP request or some other parameter passed in > the method. No. I assume that every component knows, because it's instantiated specifically for that tenant. > This is not true, as for example in the Shindig case. The Shindig API does > not pass http requests and so you cannot resolve the tenant.id from a http > request or from any argument passed to the method. Still, some Shindig > services need to be made tenant aware, like the persistent storage that > manages opensocial persons (associated with users in UserAdmin, which > are/will be tenant aware). If a Shindig service (let's call it Storage) is tenant aware, it publishes a storage service for each tenant with the appropriate tentant.id. If a consumer of that service is also tenant aware, it will know its tenant.id and make sure it depends on the right Storage service. > I do understand the downsides of using ThreadLocal variables (and already > experienced some of them, like thread pooling), but when you look at my > context patch you will see that using ThreadLocal variables is in fact an > implementation detail. But again, without using ThreadLocal variables; how > would you resolve the proper tenant in this Shindig API method? > > Public List<Person> PersonService.getPersons() I would have multiple implementations of that service. Greetings, Marcel _______________________________________________ Amdatu-developers mailing list Amdatu-developers at amdatu.org http://lists.amdatu.org/mailman/listinfo/amdatu-developers
