On Friday, June 8, 2012, Senaka Fernando 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. >
Super tenant domain is an internal concept. It should not appear in the URL . Shankar > 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]** 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* > > -- S.Uthaiyashankar Senior Software Architect Chair, Management Committee – Cloud Technologies WSO2 Inc. http://wso2.com/ - "lean . enterprise . middleware" Phone: +94 714897591
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
