Hi Dimuthu, Chethiya,

Please make sure that this does not cause integration test failures in
products. We can't accept any new fix to the kernel that breaks integration
tests in the products from this point onwards. Also, if these fixes to the
kernel need migration scripts, the Platform MC needs to start building them
right now. Please note.

Thanks,
Senaka.

On Sat, Jun 9, 2012 at 12:26 PM, Dimuthu Leelarathne <[email protected]>wrote:

>
> Hi Senaka,
>
> Please note my previous mail.
>
>
> - if (tenantDomain == null)
> +if (MultitenantConstants.SUPER_TENANT_DOMAIN_NAME.equals(tenantDomain)) {
>  +//do super tenant something
> +} else if (teanantDomain == null) {
> +//do something - prolly throw exception
> +}
>
>
> Chethiya started throwing IllegalStateException. We started doing changes
> yesterday on the trunk - will commit once all test cases are passing.
>
>
> thanks,
> dimuthu
>
>
> On Fri, Jun 8, 2012 at 11:25 PM, Senaka Fernando <[email protected]> wrote:
>
>> Hi all,
>>
>> Dimuthu, I believe that Azeez and I share the same view here.
>> tenantDomain == null means, either we didn't find the tenant or the tenant
>> information was never recorded due to some initialization error. And, the
>> super tenant would always need to be recognized by the constant. Now, this
>> is similar to what you've suggested in a way but my question is not
>> properly answered by that solution.
>>
>> My concern is, if super tenant now has a domain, the tenant domain should
>> start appearing in each request, each URL, and every single incoming
>> message. But this is not what we have been doing. Even after fixing this,
>> we still have not changed what we have been doing. For the super tenant
>> requests, we still don't have the tenantDomain being specified in the very
>> same manner as for a normal tenant. I've noticed that Pradeep's fixes to
>> the registry kernel preserves this behavior. But, what I'm not sure is how
>> are we going to keep doing the same in the future, because in such
>> situations, no tenantDomain is present.
>>
>> Therefore, we need a solid answer for what's the proper approach. I
>> noticed that Achala pointed out the same thing in another thread.
>>
>> Thanks,
>> Senaka.
>>
>>
>> On Fri, Jun 8, 2012 at 4:23 PM, Afkham Azeez <[email protected]> wrote:
>>
>>> Going forward, tenantDomain == null means only one thing. We don't know
>>> who the tenant is or tenant hasn't been initialized, so we have to fail if
>>> we are trying to perform some restricted operations.
>>>
>>>  On Thu, Jun 7, 2012 at 8:13 PM, Senaka Fernando <[email protected]>wrote:
>>>
>>>>  Hi Pradeep,
>>>>
>>>> Going through the code in Registry Kernel I discovered that you have
>>>> made changes to determine whether you are super tenant as follows:
>>>>
>>>> tenantDomain == null ||
>>>> MultitenantConstants.SUPER_TENANT_DOMAIN_NAME.equals(tenantDomain)
>>>>
>>>> Is this correct? Why are we checking for null or some constant?
>>>>
>>>> Thanks,
>>>> Senaka.
>>>>
>>>> --
>>>> *Senaka Fernando*
>>>> Member - Integration Technologies Management Committee;
>>>> Technical Lead; WSO2 Inc.; http://wso2.com*
>>>> Member; Apache Software Foundation; http://apache.org
>>>>
>>>> E-mail: senaka AT wso2.com
>>>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818
>>>> Linked-In: http://linkedin.com/in/senakafernando
>>>>
>>>> *Lean . Enterprise . Middleware
>>>>
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [email protected]
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>> *Afkham Azeez*
>>> Director of Architecture; WSO2, Inc.; http://wso2.com
>>> Member; Apache Software Foundation; http://www.apache.org/
>>> * <http://www.apache.org/>**
>>> email: **[email protected]* <[email protected]>* cell: +94 77 3320919
>>> blog: **http://blog.afkham.org* <http://blog.afkham.org>*
>>> twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>>> *
>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>>>
>>> *
>>> *
>>> *Lean . Enterprise . Middleware*
>>>
>>>
>>
>>
>> --
>> *Senaka Fernando*
>> Member - Integration Technologies Management Committee;
>> Technical Lead; WSO2 Inc.; http://wso2.com*
>> Member; Apache Software Foundation; http://apache.org
>>
>> E-mail: senaka AT wso2.com
>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818
>> Linked-In: http://linkedin.com/in/senakafernando
>>
>> *Lean . Enterprise . Middleware
>>
>>
>
>
> --
> Dimuthu Leelarathne
> Architect & Co-Chair of Platform Management Committee
>
> WSO2, Inc. (http://wso2.com)
> email:
> [email protected]
>
> Lean . Enterprise . Middleware
>
>


-- 
*Senaka Fernando*
Member - Integration Technologies Management Committee;
Technical Lead; WSO2 Inc.; http://wso2.com*
Member; Apache Software Foundation; http://apache.org

E-mail: senaka AT wso2.com
**P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818
Linked-In: http://linkedin.com/in/senakafernando

*Lean . Enterprise . Middleware
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to