Nigel Deakin wrote on 01/25/12 04:24:
> On 24/01/2012 22:57, Bill Shannon wrote:
>> We've been considering how to provide access to the Tenant ID for
>> the current tenant of a SaaS application. After discussing this
>> issue with our security team, they wrote up the following proposal.
>
>>
>> - Proposal for the EE Platform Specification
>>
>> Platform implementations would be told to make the effective TenantID
>> available in some well known location in JNDI. They would be free to
>> implement a proprietary API to access it and do whatever tenant
>> specific activities based on its value. However, consumers should be
>> able to count on the value being in JNDI as the standard mechanism.
>>
>> The language to describe what this TenantID represents must be
>> sufficiently clear in illustrating that it represents the customer for
>> which the SaaS application instance has been deployed.
>>
>> The name java:comp/tenantId would probably be sufficient for JNDI lookup.
>>
>
> Is it intended that this mechanism also be used by resource adapters to access
> the TenantID?
Yes.
> Does the Java EE specification currently require that a resource adapter is able
> to instantiate an InitialContext with no parameters and use it to access the
> JNDI provider? (Obviously they couldn't make use of resource injection to obtain
> it)
Yes. Note that they'll be accessing the JNDI context of the component calling
the resource adapter. Resource adapters don't get their own JNDI context.
Obviously since a resource adapter might be used by many applications, and
it doesn't get to control what's in the JNDI namespace for those applications,
there's a limit to what it can usefully expect to find in the JNDI namespace.
These container-defined entries are something that it would be safe for a
resource adapter to access.