Hi Shariq, Yes it's null even then.
Then, at the login time, I put a conditional breakpoint inside getUsername(), checking [username != null], and it was never hit. Which means getUsername() always returns null during login time. Thanks, Dulanja On Tue, Jan 15, 2013 at 11:22 AM, Muhammed Shariq <[email protected]> wrote: > 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
