On Jan 3, 2011, at 13:54 , Ivo Ladage-van Doorn wrote: >>> Regarding the context; if we do not store context information in a Thread >>> local variable and we do not want to pass around contextual properties in >>> each method invocation; how would you determine contextual information? I >>> discussed the Thread local stuff with Mark and Bram last week, but there >>> just isn't an alternative. Any BLOG you read about Thread locals being so >>> evil doesn't come with an alternative, or comes up with an alternative >>> which in the end still uses Thread locals in its heart. So what would you >>> suggest? >> >> This: >> >>>> If a service is tenant unaware but it has dependencies on tenant aware >>>> services, you have just made it tenant aware by definition. >> >> So if you start deploying multiple tenants in a single container, then there >> is no such thing as a service that is not tenant aware that has a dependency >> on a service that is. > > I do not understand what you mean. In the current implementation, I need to > specifically define tenant service properties on the service dependency to > get the proper tenant-aware service injected. If I don't, I will get any > service injected; which one it will be is arbitrary. If I have two of such > service dependencies, I might even get two services injected with two > different tenants. How does that make my service tenant aware?
I'm saying that every service that is tenant aware needs that tenant.id property, and that there is no such thing as a service that is not tenant aware but depends on another service that is. > Furthermore, this is not an alternative for context resolving. It could be a > possible (partial) solution in the case of tenants, but the tenant is only a > small piece of the actual context. A context will typically include the name > of the (logged in) user that send the request for example. Services need this > username for authorization checks or return user-dependent information. How > would you resolve that? Introduce user-aware services? First question that comes to mind: is Amdatu also aware of users, or just tenants? For tenants the the solution above would be enough in my opinion, so we do not need a server side context or state. Greetings, Marcel
