On Mon, Jan 14, 2013 at 5:34 PM, Dulanja Liyanage <[email protected]> wrote:
> Hi Shariq, > > After I applied the patch I couldn't login to the Management Console even. > It gave the invalid username or password message. > > When debugged, in CarbonContextDataHolder's getUsername(), both username > instance variable and MessageContext.getCurrentMessageContext() is null. So > it results in an NPE. > > Wonder I'm doing something wrong here. > Um I don't think you are doing anything wrong here .. its probably something to do with the patch .. wonder how username instance variable got null, is it null even without the patch during login ?! > > Thanks. > Dulanja > > > On Fri, Jan 11, 2013 at 6:11 PM, Dulanja Liyanage <[email protected]>wrote: > >> Hi Shariq, >> >> Sorry, I still couldn't test it because I was busy with shifting to a new >> machine. I'll let you know the result once I do it. >> >> Thanks & Regards >> Dulanja >> >> >> On Fri, Jan 11, 2013 at 2:25 PM, Muhammed Shariq <[email protected]> wrote: >> >>> Hi Dulanja, >>> >>> Use the patch attached herewith instead .. (patch_v1.diff) >>> >>> On Fri, Jan 11, 2013 at 12:34 PM, Muhammed Shariq <[email protected]>wrote: >>> >>>> On Thu, Jan 10, 2013 at 10:25 AM, Afkham Azeez <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Jan 10, 2013 at 10:14 AM, Muhammed Shariq <[email protected]>wrote: >>>>> >>>>>> On Thu, Jan 10, 2013 at 10:01 AM, Afkham Azeez <[email protected]>wrote: >>>>>> >>>>>>> However, in cases where you are sure that the ThreadLocal CC is >>>>>>> available, you must use getThreadLocalCarbonContext because that method >>>>>>> is >>>>>>> much more efficient than getCarbonContext. What I feel is, we should >>>>>>> ensure >>>>>>> that every thread contains the ThreadLocal CC, which means we will no >>>>>>> longer need the getCurrentContext method. At that point, from >>>>>>> getCurrentContext, we will just call getThreadLocalCarbonContext. >>>>>> >>>>>> >>>>>> This is what SInthuja did sometime ago (giving priority to the >>>>>> ThreadLocal CC), but the caused some issue as Senaka explained in his >>>>>> detailed mail .. Also I was trying to recall why I did some changes in >>>>>> CarbonTomcatValve, and that too was fixing the same issue (username being >>>>>> null!), I fixed it by setting the username to the CC from the session, >>>>>> this >>>>>> also was causing a perf issue cz of the getSession() gets called for >>>>>> every >>>>>> request ..! Guess we need to look into the use of CC api in a bit more >>>>>> detail .. >>>>>> >>>>> >>>>> You fix was probably the right one. The problem should be >>>>> unnecessarily accessing the session. Instead, what you could have done >>>>> was, >>>>> when someone called getUserName, at that point, get the session, and >>>>> retrieve the username & set it as an attribute in the CC. In subsequent >>>>> calls to the the same CC, you could simply return that attribute. >>>>> >>>> >>>> Yup at the moment it getUsername() simply returns what is assigned, if >>>> its null it doesn't try to fetch it. Also I I guess >>>> getThreadLocalCarbonContext() and getCarbonContext should have the >>>> same behavior isn't it?! And we should be able to use the ThreadLocal CC at >>>> anytime .. (at the moment this is not possible, we had to revert the patch >>>> that gave priority to thread local CC!) .. >>>> >>>> What we are doing in CarbonContext.getCUrrentContext() is give priority >>>> to MessageContext, since message context have all the information it gets >>>> populated (AFAIU :)) .. ThreadLocal CC is the last option and I guess it >>>> doesn't have all the information (cz MessageContext & ConfigurationContext >>>> happens to be null) .. so in that case we should populate those null fields >>>> .. hope what I am saying makes sense, thought I had it figured at the time >>>> but it seems a lil blur again! >>>> >>>> However for this particular case I have prepared a patch that tried to >>>> fetch username from the session within MessageContext .. so again if >>>> MessageContext is null username is gonna be null. Please have a look and >>>> check if it is correct ... >>>> >>>> @Dulanja - can you apply the attached path to carbon.utils and use the >>>> ThreadLocal CC and see if your getting the correct username ?! >>>> >>>>> >>>>> >>>>>> >>>>>>> Azeez >>>>>>> >>>>>>> On Wed, Jan 9, 2013 at 4:19 PM, Dimuthu Leelarathne < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Dulanja, >>>>>>>> >>>>>>>> It is correct to use CurrentCarbonContext instead of >>>>>>>> ThreadLocalCarbonContext. You can read the mail titled "UserRegistry >>>>>>>> sends >>>>>>>> null to JDBCAuthorizationManager" from archives. Basically this is the >>>>>>>> code that finds you the correct CurrentCarbonContext. So correct >>>>>>>> thing is >>>>>>>> to first get CarbonContext from MessageContext and if it is not >>>>>>>> available >>>>>>>> try the TreadLocal one. >>>>>>>> >>>>>>>> public static CarbonContextDataHolder >>>>>>>> getCurrentCarbonContextHolder() { >>>>>>>> try { >>>>>>>> MessageContext messageContext = >>>>>>>> MessageContext.getCurrentMessageContext(); >>>>>>>> if (messageContext != null) { >>>>>>>> return >>>>>>>> getCurrentCarbonContextHolder(messageContext); >>>>>>>> } else { >>>>>>>> return >>>>>>>> getCurrentCarbonContextHolder((ConfigurationContext) null); >>>>>>>> } >>>>>>>> } catch (NullPointerException ignore) { >>>>>>>> // This is thrown when the message context is not >>>>>>>> initialized >>>>>>>> // So return the Threadlocal >>>>>>>> return getThreadLocalCarbonContextHolder(); >>>>>>>> } catch (NoClassDefFoundError ignore) { >>>>>>>> // There can be situations where the CarbonContext is >>>>>>>> accessed, when there is no Axis2 >>>>>>>> // library on the classpath. >>>>>>>> return getThreadLocalCarbonContextHolder(); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> thanks, >>>>>>>> dimuthu >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jan 9, 2013 at 2:15 PM, Dulanja Liyanage >>>>>>>> <[email protected]>wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Appreciate if you can guide me whether it's safe/appropriate to >>>>>>>>> use the CurrentContext rather than the ThreadLocalCarbonContext, to >>>>>>>>> get the >>>>>>>>> username and tenant domain. >>>>>>>>> >>>>>>>>> I'm not much knowledgeable about the design, but I feel using it >>>>>>>>> will be "plastering" the root cause. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dulanja >>>>>>>>> >>>>>>>>> On Wed, Jan 9, 2013 at 12:18 PM, Dulanja Liyanage < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi Shariq, >>>>>>>>>> >>>>>>>>>> I did as you suggested and now the username is available. >>>>>>>>>> >>>>>>>>>> What I'm not sure is how appropriate/safe this is. >>>>>>>>>> >>>>>>>>>> Thanks for the help. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Dulanja >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jan 8, 2013 at 6:17 PM, Dulanja Liyanage < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Shariq, >>>>>>>>>>> >>>>>>>>>>> I will try that. Thanks! >>>>>>>>>>> >>>>>>>>>>> Dulanja >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Jan 8, 2013 at 6:12 PM, Muhammed Shariq <[email protected] >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> This looks like an issue I encountered sometime back. We had to >>>>>>>>>>>> revert the fixes I did in TomcatValve cz it was causing some other >>>>>>>>>>>> issue .. >>>>>>>>>>>> Can you try CarbonContext.getCurrentContext.getUsername() and see >>>>>>>>>>>> what >>>>>>>>>>>> happens .. AFAIR its getUsername simple does a return .. we should >>>>>>>>>>>> fix it >>>>>>>>>>>> to check if username is null and if so set it properly .. usually >>>>>>>>>>>> that is >>>>>>>>>>>> the behavior but there are some edge cases it seem ... >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jan 8, 2013 at 3:53 PM, Dulanja Liyanage < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I'm testing IS 4.1.0 running on Carbon 4.0.6. While debugging >>>>>>>>>>>>> an issue, I encountered the $subject. >>>>>>>>>>>>> >>>>>>>>>>>>> I logged in as 'admin', so, the username should return as >>>>>>>>>>>>> such. But it returns 'null'. >>>>>>>>>>>>> >>>>>>>>>>>>> However the >>>>>>>>>>>>> PrivilegedCarbonContext.getThreadLocalCarbonContext().getTenantDomain() >>>>>>>>>>>>> returns 'carbon.super' as expected. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm still debugging this and trying to figure out how >>>>>>>>>>>>> CarbonContext works in threads. If someone is already aware of a >>>>>>>>>>>>> reason/solution for this it will save time. :) >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> Dulanja >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Dev mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Shariq. >>>>>>>>>>>> Phone: +94 777 202 225 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Dev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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* >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> [email protected] >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> Shariq. >>>>>> Phone: +94 777 202 225 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *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* >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks, >>>> Shariq. >>>> Phone: +94 777 202 225 >>>> >>> >>> >>> >>> -- >>> Thanks, >>> Shariq. >>> Phone: +94 777 202 225 >>> >> >> > -- Thanks, Shariq. Phone: +94 777 202 225
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
