Re: [Dev] PrivilegedCarbonContext.getThreadLocalCarbonContext().getUsername() returns 'null'
Hi Dimuthu,
Thanks a lot for the explanation and pointing to the mail thread.
Regards,
Dulanja
On Wed, Jan 9, 2013 at 4:19 PM, Dimuthu Leelarathne dimut...@wso2.comwrote:
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 dula...@wso2.com 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 dula...@wso2.comwrote:
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 dula...@wso2.comwrote:
Hi Shariq,
I will try that. Thanks!
Dulanja
On Tue, Jan 8, 2013 at 6:12 PM, Muhammed Shariq sha...@wso2.comwrote:
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 dula...@wso2.comwrote:
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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
--
Thanks,
Shariq.
Phone: +94 777 202 225
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [Bamboo-Build] WSO2 Carbon 4.0.x Platform 4.0.6 #29 has FAILED (1 tests failed, no failures were new). Change made by hasithah, reka and thilini.
--- WSO2 Carbon 4.0.x Platform 4.0.6 #29 failed. --- Code has been updated by hasithah, reka, thilini. 1/888 tests failed, no failures were new. http://wso2.org/bamboo/browse/WCB001-PLA006-29/ - Currently Responsible - No one is responsible for fixing this build. -- Failing Jobs -- - Default Job (Default Stage): 1 of 888 tests failed. -- Code Changes -- reka (152927): caching patch for when defining stream provided by Amani reka (152931): updating version thilini (152933): APPFAC-215: changing the task status to in_progress upon taks creation -- Tests -- Existing Test Failures (1) - MultipleDefinitionConversionTest: Multiple defn conversion from j s o n -- This message is automatically generated by Atlassian Bamboo___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [Bamboo-Build] WSO2 Carbon 4.0.x Products 4.0.6 #29 was SUCCESSFUL (with 18 tests). Change made by hasithah, reka and thilini.
--- WSO2 Carbon 4.0.x Products 4.0.6 #29 was successful. --- Code has been updated by hasithah, reka, thilini. 18 tests in total. http://wso2.org/bamboo/browse/WCB001-PRO006-29/ -- Code Changes -- reka (152927): caching patch for when defining stream provided by Amani reka (152931): updating version thilini (152933): APPFAC-215: changing the task status to in_progress upon taks creation -- This message is automatically generated by Atlassian Bamboo___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [Bamboo-Build] WSO2 Carbon 4.0.x Platform 4.0.6 #30 has FAILED (1 tests failed, no failures were new). Change made by hasithah and dushan.
--- WSO2 Carbon 4.0.x Platform 4.0.6 #30 failed. --- Code has been updated by hasithah, dushan. 1/888 tests failed, no failures were new. http://wso2.org/bamboo/browse/WCB001-PLA006-30/ - Currently Responsible - No one is responsible for fixing this build. -- Failing Jobs -- - Default Job (Default Stage): 1 of 888 tests failed. -- Code Changes -- hasithah (152937): updated pom.xml file to refer carbon core 4.0.6. hasithah (152936): updated pom.xml to refer cabon core 4.0.6. hasithah (152935): updated pom.xml to refer carbon core 4.0.6. -- Tests -- Existing Test Failures (1) - MultipleDefinitionConversionTest: Multiple defn conversion from j s o n -- This message is automatically generated by Atlassian Bamboo___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [Bamboo-Build] WSO2 Carbon 4.0.x Platform 4.0.6 #30 has FAILED (1 tests failed, no failures were new). Change made by hasithah and dushan.
Hi Suho, multipleDefnConversionFromJSON test is failing. Please have a look. On Wed, Jan 9, 2013 at 9:22 PM, Bamboo cbuil...@wso2.org wrote: [image: Failed] WSO2 Carbon 4.0.xhttp://wso2.org/bamboo/browse/WCB001/› Platform 4.0.6 http://wso2.org/bamboo/browse/WCB001-PLA006/ › #30http://wso2.org/bamboo/browse/WCB001-PLA006-30/ failed Changes by hasithah http://wso2.org/bamboo/browse/author/hasithah and dushan http://wso2.org/bamboo/browse/author/dushan *1/888* tests failed. Responsible No one is responsible for this build. Failing Jobs http://wso2.org/bamboo/browse/WCB001-PLA006-30/ Job Duration Tests[image: Failed] Default Jobhttp://wso2.org/bamboo/browse/WCB001-PLA006-JOB1-30/ (Default Stage) 12 minutes 1 of 888 failed Logshttp://wso2.org/bamboo/browse/WCB001-PLA006-JOB1-30/log| Artifacts http://wso2.org/bamboo/browse/WCB001-PLA006-JOB1-30/artifact Code Changes http://wso2.org/bamboo/browse/WCB001-PLA006-30/commit/ View all 4 code changeshttp://wso2.org/bamboo/browse/WCB001-PLA006-30/commit/ dushan http://wso2.org/bamboo/browse/author/dushan added esb patch build profile 152941 hasithahhttp://wso2.org/bamboo/browse/author/hasithah updated pom.xml file to refer carbon core 4.0.6. 152937 hasithahhttp://wso2.org/bamboo/browse/author/hasithah updated pom.xml to refer cabon core 4.0.6. 152936 1 more changes…http://wso2.org/bamboo/browse/WCB001-PLA006-30/commit Tests http://wso2.org/bamboo/browse/WCB001-PLA006-30/test View full test details http://wso2.org/bamboo/browse/WCB001-PLA006-30/test 1 Existing Test Failures Test Job MultipleDefinitionConversionTest multipleDefnConversionFromJSONhttp://wso2.org/bamboo/browse/WCB001-PLA006-JOB1-30/test/case/41485811 Default Job http://wso2.org/bamboo/browse/WCB001-PLA006-JOB1-30/test View Online http://wso2.org/bamboo/browse/WCB001-PLA006-30 | Add Commentshttp://wso2.org/bamboo/browse/WCB001-PLA006-30?commentMode=true This message was sent by Atlassian Bamboo http://wso2.org/bamboo. If you wish to stop receiving these emails edit your user profilehttp://wso2.org/bamboo/profile/userNotifications.actionor notify your administrator http://wso2.org/bamboo/viewAdministrators.action. ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev -- *Amila Maharachchi* Technical Lead Member, Management Committee - Cloud Platform TG WSO2, Inc.; http://wso2.com Blog: http://maharachchi.blogspot.com Mobile: +94719371446 ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [Bamboo-Build] WSO2 Carbon 4.0.x Products 4.0.6 #30 was SUCCESSFUL (with 18 tests). Change made by hasithah and dushan.
--- WSO2 Carbon 4.0.x Products 4.0.6 #30 was successful. --- Code has been updated by hasithah, dushan. 18 tests in total. http://wso2.org/bamboo/browse/WCB001-PRO006-30/ -- Code Changes -- hasithah (152937): updated pom.xml file to refer carbon core 4.0.6. hasithah (152936): updated pom.xml to refer cabon core 4.0.6. hasithah (152935): updated pom.xml to refer carbon core 4.0.6. -- This message is automatically generated by Atlassian Bamboo___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [Bamboo-Build] WSO2 Carbon 4.0.x Platform 4.0.6 #30 has FAILED (1 tests failed, no failures were new). Change made by hasithah and dushan.
On Wed, Jan 9, 2013 at 9:38 PM, Amila Maha Arachchi ami...@wso2.com wrote: Hi Suho, multipleDefnConversionFromJSON test is failing. Please have a look. Thanks, I have fixed it. Suho On Wed, Jan 9, 2013 at 9:22 PM, Bamboo cbuil...@wso2.org wrote: [image: Failed] WSO2 Carbon 4.0.xhttp://wso2.org/bamboo/browse/WCB001/› Platform 4.0.6 http://wso2.org/bamboo/browse/WCB001-PLA006/ › #30http://wso2.org/bamboo/browse/WCB001-PLA006-30/ failed Changes by hasithah http://wso2.org/bamboo/browse/author/hasithah and dushan http://wso2.org/bamboo/browse/author/dushan *1/888* tests failed. Responsible No one is responsible for this build. Failing Jobs http://wso2.org/bamboo/browse/WCB001-PLA006-30/ Job Duration Tests[image: Failed] Default Jobhttp://wso2.org/bamboo/browse/WCB001-PLA006-JOB1-30/ (Default Stage) 12 minutes 1 of 888 failed Logshttp://wso2.org/bamboo/browse/WCB001-PLA006-JOB1-30/log| Artifacts http://wso2.org/bamboo/browse/WCB001-PLA006-JOB1-30/artifact Code Changes http://wso2.org/bamboo/browse/WCB001-PLA006-30/commit/ View all 4 code changeshttp://wso2.org/bamboo/browse/WCB001-PLA006-30/commit/ dushan http://wso2.org/bamboo/browse/author/dushan added esb patch build profile 152941 hasithahhttp://wso2.org/bamboo/browse/author/hasithah updated pom.xml file to refer carbon core 4.0.6. 152937 hasithahhttp://wso2.org/bamboo/browse/author/hasithah updated pom.xml to refer cabon core 4.0.6. 152936 1 more changes…http://wso2.org/bamboo/browse/WCB001-PLA006-30/commit Tests http://wso2.org/bamboo/browse/WCB001-PLA006-30/test View full test details http://wso2.org/bamboo/browse/WCB001-PLA006-30/test 1 Existing Test Failures Test Job MultipleDefinitionConversionTest multipleDefnConversionFromJSONhttp://wso2.org/bamboo/browse/WCB001-PLA006-JOB1-30/test/case/41485811 Default Job http://wso2.org/bamboo/browse/WCB001-PLA006-JOB1-30/test View Online http://wso2.org/bamboo/browse/WCB001-PLA006-30 | Add Commentshttp://wso2.org/bamboo/browse/WCB001-PLA006-30?commentMode=true This message was sent by Atlassian Bamboo http://wso2.org/bamboo. If you wish to stop receiving these emails edit your user profilehttp://wso2.org/bamboo/profile/userNotifications.actionor notify your administrator http://wso2.org/bamboo/viewAdministrators.action. ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev -- *Amila Maharachchi* Technical Lead Member, Management Committee - Cloud Platform TG WSO2, Inc.; http://wso2.com Blog: http://maharachchi.blogspot.com Mobile: +94719371446 -- *S. Suhothayan * Software Engineer, Data Technologies Team, *WSO2, Inc. **http://wso2.com http://wso2.com/* *lean.enterprise.middleware.* *email: **s...@wso2.com* s...@wso2.com* cell: (+94) 779 756 757 blog: **http://suhothayan.blogspot.com/* http://suhothayan.blogspot.com/* twitter: **http://twitter.com/suhothayan* http://twitter.com/suhothayan* linked-in: **http://lk.linkedin.com/in/suhothayan* * * ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [Bamboo-Build] WSO2 Carbon 4.0.x Products 4.0.6 #31 was SUCCESSFUL (with 18 tests). Change made by suho.
--- WSO2 Carbon 4.0.x Products 4.0.6 #31 was successful. --- Code has been updated by suho. 18 tests in total. http://wso2.org/bamboo/browse/WCB001-PRO006-31/ -- Code Changes -- suho (152946): fixing multipleDefnConversionFromJSON test -- This message is automatically generated by Atlassian Bamboo___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [Bamboo-Build] WSO2 Carbon 4.0.x Platform 4.0.6 #31 was SUCCESSFUL (with 888 tests). Change made by suho.
--- WSO2 Carbon 4.0.x Platform 4.0.6 #31 was successful. --- Code has been updated by suho. 888 tests in total. http://wso2.org/bamboo/browse/WCB001-PLA006-31/ -- Code Changes -- suho (152946): fixing multipleDefnConversionFromJSON test -- Tests -- Fixed Tests (1) - MultipleDefinitionConversionTest: Multiple defn conversion from j s o n -- This message is automatically generated by Atlassian Bamboo___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] PrivilegedCarbonContext.getThreadLocalCarbonContext().getUsername() returns 'null'
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.
Azeez
On Wed, Jan 9, 2013 at 4:19 PM, Dimuthu Leelarathne dimut...@wso2.comwrote:
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 dula...@wso2.com 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 dula...@wso2.comwrote:
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 dula...@wso2.comwrote:
Hi Shariq,
I will try that. Thanks!
Dulanja
On Tue, Jan 8, 2013 at 6:12 PM, Muhammed Shariq sha...@wso2.comwrote:
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 dula...@wso2.comwrote:
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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
--
Thanks,
Shariq.
Phone: +94 777 202 225
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
___
Dev mailing list
Dev@wso2.org
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: **az...@wso2.com* az...@wso2.com* 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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] P2 Category re-factoring by introducing sub-categories
On Mon, Jan 7, 2013 at 9:42 PM, Dileepa Jayakody dile...@wso2.com wrote: Hi All, Continuing the previous discussions we had on re-factoring P2-feature categories to achieve fine-grained sub-level groupings of features under products, we decided to introduce new composite-features corresponding to sub-categories under each product in the p2-repository. This has been already done for Application Server (see the attached screen-shot on how AS category is now listed down in the p2-repo). The set of AS composite-features defined for this purpose can be found at [1]. Similarly composite features for all other products can be created at above location (eg: composite-features/esb, composite-features/greg etc.) It'll be great if all product categories in our p2-repo can be cleaned and re-factored by including sub-categories. Product teams can decide how they want to organize their product category into sub-categories based on the expected functionality of features. @Product teams, please create relevant composite-features and re-factor your p2-category by including sub-categories in the p2-repo. Hi Vijitha, Please note, since G-Reg 4.5.6 will release before mid Feb, we need to add the composite feature layer quite sooner before the release so that we have time to make sure everything works properly with this change before the release. If you need more insight on p2 sub-category concept please refer the blog-post here [2]. For step-by-step instructions on how to create composite-features and add them to the p2-repository please follow the blog-post here [3]. I hope above blog-posts can help you to get an understanding of what needs to be done. Further, if a member of each product team can own this task, I can help them in-person as well. Thanks, Dileepa [1] https://svn.wso2.org/repos/wso2/carbon/platform/branches/4.0.0/features/composite-features/as/ [2] http://dileepajayakody.blogspot.com/2012/12/how-to-achieve-sub-categorization-in.html [3] http://dileepajayakody.blogspot.com/2012/12/how-to-generate-sub-categories-for-wso2.html -- Dileepa Jayakody, Software Engineer, WSO2 Inc. Lean . Enterprise . Middleware Mobile : +94777-857616 -- Subash Chaturanga Software Engineer WSO2 Inc. http://wso2.com email - sub...@wso2.com phone - 077 2225922 ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] Implementation of the REST API on G-Reg
Hai All, The REST API currently implemented as a web - application. The web application get an remote registry instance to access the registry components. The current implementation does the necessary resource related operations using the instance of the remote registry. eg( adding comments/rating/tags ..etc on the resource). After I had the offline chat with G-Reg team, we now plan to move the REST api into the platform/registry components as a separate OSGI bundle. I did the necessary changes to the current app and moved to the above location and checked whether the REST api bundle is active/enabled when the G-Reg instance is started. Yes, it was enabled. I would like to know your opinion on how the REST API implementation need to be adapted to G-Reg. or How Do I need to implement this REST API by means some other products also can access? Thanks! Regards, Sriragu ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] PrivilegedCarbonContext.getThreadLocalCarbonContext().getUsername() returns 'null'
On Thu, Jan 10, 2013 at 10:01 AM, Afkham Azeez az...@wso2.com 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 ..
Azeez
On Wed, Jan 9, 2013 at 4:19 PM, Dimuthu Leelarathne dimut...@wso2.comwrote:
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 dula...@wso2.comwrote:
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 dula...@wso2.comwrote:
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 dula...@wso2.comwrote:
Hi Shariq,
I will try that. Thanks!
Dulanja
On Tue, Jan 8, 2013 at 6:12 PM, Muhammed Shariq sha...@wso2.comwrote:
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 dula...@wso2.comwrote:
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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
--
Thanks,
Shariq.
Phone: +94 777 202 225
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
___
Dev mailing list
Dev@wso2.org
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: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
blog: **http://blog.afkham.org* http://blog.afkham.org*
twitter:
Re: [Dev] PrivilegedCarbonContext.getThreadLocalCarbonContext().getUsername() returns 'null'
On Thu, Jan 10, 2013 at 10:14 AM, Muhammed Shariq sha...@wso2.com wrote:
On Thu, Jan 10, 2013 at 10:01 AM, Afkham Azeez az...@wso2.com 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.
Azeez
On Wed, Jan 9, 2013 at 4:19 PM, Dimuthu Leelarathne dimut...@wso2.comwrote:
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 dula...@wso2.comwrote:
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 dula...@wso2.comwrote:
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 dula...@wso2.comwrote:
Hi Shariq,
I will try that. Thanks!
Dulanja
On Tue, Jan 8, 2013 at 6:12 PM, Muhammed Shariq sha...@wso2.comwrote:
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
dula...@wso2.comwrote:
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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
--
Thanks,
Shariq.
Phone: +94 777 202 225
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] PrivilegedCarbonContext.getThreadLocalCarbonContext().getUsername() returns 'null'
Thanks Azeez and Shariq for the inputs :)
On Thu, Jan 10, 2013 at 10:25 AM, Afkham Azeez az...@wso2.com wrote:
On Thu, Jan 10, 2013 at 10:14 AM, Muhammed Shariq sha...@wso2.com wrote:
On Thu, Jan 10, 2013 at 10:01 AM, Afkham Azeez az...@wso2.com 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.
Azeez
On Wed, Jan 9, 2013 at 4:19 PM, Dimuthu Leelarathne
dimut...@wso2.comwrote:
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 dula...@wso2.comwrote:
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 dula...@wso2.comwrote:
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 dula...@wso2.comwrote:
Hi Shariq,
I will try that. Thanks!
Dulanja
On Tue, Jan 8, 2013 at 6:12 PM, Muhammed Shariq sha...@wso2.comwrote:
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
dula...@wso2.comwrote:
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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
--
Thanks,
Shariq.
Phone: +94 777 202 225
Re: [Dev] Implementation of the REST API on G-Reg
Hi Ragu, Is OAuth based security implemented for this? If not, lets do that first. Once done, lets have a review of the design and the code. Next step would be to document the entire API and provide some sample(s) explaining how this can be used. Thanks, Senaka. On Thu, Jan 10, 2013 at 10:13 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hai All, The REST API currently implemented as a web - application. The web application get an remote registry instance to access the registry components. The current implementation does the necessary resource related operations using the instance of the remote registry. eg( adding comments/rating/tags ..etc on the resource). After I had the offline chat with G-Reg team, we now plan to move the REST api into the platform/registry components as a separate OSGI bundle. I did the necessary changes to the current app and moved to the above location and checked whether the REST api bundle is active/enabled when the G-Reg instance is started. Yes, it was enabled. I would like to know your opinion on how the REST API implementation need to be adapted to G-Reg. or How Do I need to implement this REST API by means some other products also can access? Thanks! Regards, Sriragu -- * http://wso2con.com/ * * 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 Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] Carbon Kernal build error any idea?
This occurred to me too..
On Thu, Jan 3, 2013 at 4:42 PM, Malaka Silva mal...@wso2.com wrote:
[DEBUG] Looking up lifecyle mappings for packaging jar from
ClassRealm[projectorg.wso2.carbon:carbon:4.0.0, parent:
ClassRealm[maven.api, parent: null]]
[ERROR] The build could not read 1 project - [Help 1]
org.apache.maven.project.ProjectBuildingException: Some problems were
encountered while processing the POMs:
[FATAL] Non-resolvable parent POM: Failure to find
org.wso2.carbon:integration:pom:4.0.0 in
http://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced and 'parent.relativePath' points at wrong
local POM @ line 22, column 13
[WARNING] The expression ${pom.version} is deprecated. Please use
${project.version} instead. @
[WARNING] The expression ${pom.version} is deprecated. Please use
${project.version} instead. @
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
--
*Chamara Ariyarathne*
Senior Software Engineer - QA;
WSO2 Inc; http://www.wso2.com/.
Mobile; *+94772786766*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] Implementation of the REST API on G-Reg
Hai Senaka, OAuth not yet implemented. I will do that first. I think OAuth is mainly implemented in IS. I think I have to implement the integration part of the OAuth to the rest api. Please tell me your ideas how can I approach this situation? What else I need to be considered when implement this? Ragu On Thu, Jan 10, 2013 at 11:03 AM, Senaka Fernando sen...@wso2.com wrote: Hi Ragu, Is OAuth based security implemented for this? If not, lets do that first. Once done, lets have a review of the design and the code. Next step would be to document the entire API and provide some sample(s) explaining how this can be used. Thanks, Senaka. On Thu, Jan 10, 2013 at 10:13 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hai All, The REST API currently implemented as a web - application. The web application get an remote registry instance to access the registry components. The current implementation does the necessary resource related operations using the instance of the remote registry. eg( adding comments/rating/tags ..etc on the resource). After I had the offline chat with G-Reg team, we now plan to move the REST api into the platform/registry components as a separate OSGI bundle. I did the necessary changes to the current app and moved to the above location and checked whether the REST api bundle is active/enabled when the G-Reg instance is started. Yes, it was enabled. I would like to know your opinion on how the REST API implementation need to be adapted to G-Reg. or How Do I need to implement this REST API by means some other products also can access? Thanks! Regards, Sriragu -- * http://wso2con.com/ * * 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 Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] Implementation of the REST API on G-Reg
Hi Ragu, OAuth is not strictly a part of IS according to my understanding. It is a reusable component in our platform, and we should be able to make use of it without much of a hassle. Thanks, Senaka. On Thu, Jan 10, 2013 at 11:16 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Senaka, OAuth not yet implemented. I will do that first. I think OAuth is mainly implemented in IS. I think I have to implement the integration part of the OAuth to the rest api. Please tell me your ideas how can I approach this situation? What else I need to be considered when implement this? Ragu On Thu, Jan 10, 2013 at 11:03 AM, Senaka Fernando sen...@wso2.com wrote: Hi Ragu, Is OAuth based security implemented for this? If not, lets do that first. Once done, lets have a review of the design and the code. Next step would be to document the entire API and provide some sample(s) explaining how this can be used. Thanks, Senaka. On Thu, Jan 10, 2013 at 10:13 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hai All, The REST API currently implemented as a web - application. The web application get an remote registry instance to access the registry components. The current implementation does the necessary resource related operations using the instance of the remote registry. eg( adding comments/rating/tags ..etc on the resource). After I had the offline chat with G-Reg team, we now plan to move the REST api into the platform/registry components as a separate OSGI bundle. I did the necessary changes to the current app and moved to the above location and checked whether the REST api bundle is active/enabled when the G-Reg instance is started. Yes, it was enabled. I would like to know your opinion on how the REST API implementation need to be adapted to G-Reg. or How Do I need to implement this REST API by means some other products also can access? Thanks! Regards, Sriragu -- * http://wso2con.com/ * * 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 -- * http://wso2con.com/ * * 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 Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] Carbon Kernal build error any idea?
Hi Chamara,
I had this problem earlier.
But it was solved after taking an update from SVN and building the patch
releases 4.0.6 of Orbit, Kernel and Platform
Best Regards,
Malaka
On Thu, Jan 10, 2013 at 11:11 AM, Chamara Ariyarathne chama...@wso2.comwrote:
This occurred to me too..
On Thu, Jan 3, 2013 at 4:42 PM, Malaka Silva mal...@wso2.com wrote:
[DEBUG] Looking up lifecyle mappings for packaging jar from
ClassRealm[projectorg.wso2.carbon:carbon:4.0.0, parent:
ClassRealm[maven.api, parent: null]]
[ERROR] The build could not read 1 project - [Help 1]
org.apache.maven.project.ProjectBuildingException: Some problems were
encountered while processing the POMs:
[FATAL] Non-resolvable parent POM: Failure to find
org.wso2.carbon:integration:pom:4.0.0 in
http://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced and 'parent.relativePath' points at wrong
local POM @ line 22, column 13
[WARNING] The expression ${pom.version} is deprecated. Please use
${project.version} instead. @
[WARNING] The expression ${pom.version} is deprecated. Please use
${project.version} instead. @
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
--
*Chamara Ariyarathne*
Senior Software Engineer - QA;
WSO2 Inc; http://www.wso2.com/.
Mobile; *+94772786766*
--
Best Regards,
Malaka
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [Bamboo-Build] WSO2 Carbon 4.0.x Products 4.0.6 #32 was SUCCESSFUL (with 18 tests). Change made by hasithah and dushan.
--- WSO2 Carbon 4.0.x Products 4.0.6 #32 was successful. --- Code has been updated by hasithah, dushan. 18 tests in total. http://wso2.org/bamboo/browse/WCB001-PRO006-32/ -- Code Changes -- dushan (152962): fixed POX security failure on DELETE hasithah (152956): updated pom.xml file. -- This message is automatically generated by Atlassian Bamboo___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
