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
