[
http://jira.amdatu.org/jira/browse/AMDATU-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10824#comment-10824
]
Bram de Kruijff commented on AMDATU-245:
----------------------------------------
Pluggable tenant resolving is now supported through thet Amdatu Web Dispatcher
extenderfilter mechanism. The Amdatu Web Project provides two resolvers
(parameter/hostname) that are deployed in the default release assembly.
> Provide pluggable mechanism for tenant resolving
> ------------------------------------------------
>
> Key: AMDATU-245
> URL: http://jira.amdatu.org/jira/browse/AMDATU-245
> Project: Amdatu
> Issue Type: Task
> Components: Amdatu Core
> Affects Versions: 0.1.0
> Reporter: Ivo Ladage - van Doorn
> Assignee: Bram de Kruijff
> Fix For: 0.1.0
>
>
> As described in the use case of http://jira.amdatu.org/jira/browse/AMDATU-84,
> we need some pluggable mechanism that facilitates tenant resolving. It should
> cover:
> - The 'current' tenant can be resolved from a hostname in a HTTP request
> - The 'current' tenant can be resolved in the shindig context. For methods
> that have access to the security token, the SecurityToken.getDomain seems to
> be the only available location to store this information. For other methods
> the tenant could only be retrieved from a context using ThreadLocal variables.
> - Preferably the 'current' tenant is available on some context. This would
> prevent the need of passing tenants to APIs that do not have access to a
> SecurityToken or HTTP request, like the LoginService.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
